<Wizzup>
uvos: wtf: Nov 23 10:47:48 localhost mce[3354]: Requesting shutdown from powerkey.c: generic_powerkey_handler(); action: 2
<Wizzup>
I'm really quite sure I didn't do that lol
<uvos>
hmm
<Wizzup>
parazyd: well this works, but if you want to try something else, ok
<Wizzup>
it's already packaged and we'd just have to change the three chars
<Wizzup>
but yeah ok, we'd have to compile it though
<Wizzup>
I'm fine either way
<uvos>
Wizzup: could be a hw glitch even (some moisture)
<Wizzup>
parazyd: so the alternative is to reply 'init' with 'ctl' in the init script
<Wizzup>
ss/reply/replace/
<parazyd>
The point is to replace a binary blob with 20 lines of C
<Wizzup>
what about the other ~3-4MB of blob :P
<Wizzup>
but ok, whatever
<parazyd>
Nothing
<parazyd>
We liberate what we can
<Wizzup>
the same code is also in the DDX fwiw
<uvos>
yeah but that dosent work
<uvos>
its to late
<Wizzup>
so why does my droid4 init
<Wizzup>
lol
<Wizzup>
I don't get it
<Wizzup>
I don't have /usr/bin/pvrsrvinit
<Wizzup>
maybe the X code does work for me?
<uvos>
Wizzup: so the code in the ddx "works" but its not sufficant because 1. there is a race with h-d, h-d might sometimes end up on llvmpipe 2. it dosent do anything for other drm applications we might want before x starts, like a bootlogo or charge-mode
<Wizzup>
ok, so I haven't seen the race yet
<Wizzup>
oh yeah there was the chargemode thing
<uvos>
particularly we need pvr to be init'ed before charging-sdl if we want charging-sdl to work on acellerated drm and not directfb
<Wizzup>
it doesn't use acceleration atm though right?
<uvos>
its on directfb so n
<uvos>
but it works fine on ddk1.17 drm i tested it before there
<uvos>
so its just a matter of flipping it over
<uvos>
then its accellerated and can turn of the display
<uvos>
so we def want that
<Wizzup>
ok
System_Error has quit [Ping timeout: 276 seconds]
<Wizzup>
so the next thing is either n900 with uImage from 5.15 or u-boot mainline
<Wizzup>
ok 2021.10 boots for me and it boots leste as well
<uvos>
i mean it might make some sense to stop recomending people attach kernels, surely we can just have people move whatever fremantle kernel they want to use somewhere else?
<uvos>
the other option is to have the install script for uboot dd the partition to an image, extact the kernel if any and reattach it
<Wizzup>
we might need attached dtb on n900?
<Wizzup>
I guess I should check
<uvos>
good question, yeah we do rn
<parazyd>
user@devuan-droid4:~$ glxgears
<parazyd>
LoadLib: Couldn't load libpvr_dri_support.so: libpvr_dri_support.so: cannot open shared object file: No such file or directory
<parazyd>
Wizzup: ^
<parazyd>
Seen this?
<uvos>
parazyd: GLXgears?
<Wizzup>
parazyd: why are you trying glx?
<Wizzup>
glx is not supported and also it's not gles
<Wizzup>
es2gears_x11 is what you want I think
<parazyd>
ah sry, I wanted to try es2gears indeed
<uvos>
it should work on llvmpipe in theroy
<Wizzup>
but, h-d is a much better test
<Wizzup>
uvos: yes but we don't want that :)
<uvos>
but its broken atm (we allready know)
<parazyd>
but the same
<parazyd>
user@devuan-droid4:~$ es2gears_x11
<parazyd>
LoadLib: Couldn't load libpvr_dri_support.so: libpvr_dri_support.so: cannot open shared object file: No such file or directory
<parazyd>
libEGL warning: DRI2: failed to create dri screen
<Wizzup>
so did you reboot to hildon-desktop and new ddx?
<parazyd>
h-d is slow, so I'd say swrast
<Wizzup>
what is the state of your system atm
<parazyd>
Wizzup: Obviously
<parazyd>
I have slow h-d running
<Wizzup>
wasn't clear to me
<Wizzup>
ok, first thing to check is /tmp/Xorg.0.log
<Wizzup>
search for any errors
<uvos>
also check you have the envvar
<Wizzup>
it's in the package
<uvos>
ok
<Wizzup>
I added it last night, it should be there
<Wizzup>
but we'll find out soon enough from Xorg.0.log
<Pali>
Setup the device tree --> A safe location is just above the 128MiB boundary from start of RAM.
<Pali>
Calling the kernel image --> The zImage may also be placed in system RAM and called there. The kernel should be placed in the first 128MiB of RAM.
<Wizzup>
ok
<Pali>
Load initramfs --> A safe location is just above the device tree blob which itself will be loaded just above the 128MiB boundary from the start of RAM as recommended above.
<Pali>
Anyway, there is standard U-Boot variable ${fdt_addr_r} which should specify address where DTB should be loaded
<Pali>
I think that n900 does not set this variable in include/configs/nokia_rx51.h (during compile time)
<Pali>
So it would be a nice to define this variable and send patch
<Pali>
And ${fdtfile} variable should contain name of (default) DTB file
<Pali>
Similarly ${kernel_addr_r} is address for zImage
<Wizzup>
ok, I'll try to figure it out and see if I can send a patch
<Pali>
n900 uses custom variables ($kernaddr, $initrdaddr, $scriptaddr), so aliases for standard variables could be useful
<Wizzup>
oh, so the addrs are already there :)
System_Error has quit [Ping timeout: 276 seconds]
<parazyd>
Wizzup: Ok, when we convert it from native to quilt, it works.
<Wizzup>
well we would have to introduce new sections
<Wizzup>
and that is not an easy upgrade path
<uvos>
Wizzup: why?
<Wizzup>
unless you want to use n900 for omap3 and droid4 for omap4
<Wizzup>
uvos: because people would have to change sources.list
<uvos>
no not that
<uvos>
ok sure we might have some problem in the future if we add a non-mapphone non-n900 omap device
<uvos>
really the current sections arnt so great anyways maybe we sould break at some point
<uvos>
needs to be well thought out tho
<parazyd>
I agree we could work on this a bit
<uvos>
i mean bionic is droid4 bionic
<uvos>
realy there sould be omap4 mapphone bionic or something like that
<Wizzup>
uvos: like xt610 :)
<uvos>
heh
<uvos>
yeah
<Wizzup>
so I went for the virtual like that because we had no easy other path, but yes we need to work on the components
<uvos>
yeah sure makes sense
<uvos>
just makes the packaging a bit ugly rn
<uvos>
as you have discoverd :)
<Wizzup>
I thought the -meta-$device could just pull the right libs
<Wizzup>
does that not work?
<uvos>
it dose
belcher has quit [Ping timeout: 245 seconds]
<uvos>
but some package needing some other package but not directly depending on it is a bit ugly
<Wizzup>
yeah
<uvos>
you might want to install hildon without going for the full meta
<Wizzup>
well that will break a lot more currently
<parazyd>
We can have a big break, but then we need to clean up everything at once.
<parazyd>
tbh it sounds better than patching solutions
<parazyd>
(And really it's not a break, just changing sources.list and dist upgrade)
<uvos>
yeah proubly fine if a short blogpost acompanies it to tell people what they need to do
<parazyd>
Exactly
<Wizzup>
why not do it with the buster+1
<parazyd>
That'd work
<parazyd>
That's the time when we rebuild everything anyway :D
<Wizzup>
I prefer that since it's obvious they should probably read the news update or flash a new image, which is better than folks not knowing what's up and upgrading and things breaking
<parazyd>
For this, I'd like that we design some doc/spec on what the repo layouts should look like next
<parazyd>
And do some prior investigation to know if it will work (and scale)
<Wizzup>
yes we can make an issue for it
<Wizzup>
with chimaere milestone
<Wizzup>
(sp)
<Wizzup>
lol
<Wizzup>
ok, will try n900 momentarily
<Wizzup>
freemangordon: you said portrait doesn't work yet right?
<sicelo>
he said so, yes
<Wizzup>
sicelo: thanks for refreshing my memory :p
belcher has joined #maemo-leste
uvos has quit [Ping timeout: 245 seconds]
<parazyd>
Sorry I dunno how to get a clean upgrade
<Wizzup>
what is the problem that you run into that doesn't work with dist-upgrade
<parazyd>
Things don't want to upgrade unless I manually install libegl1
<parazyd>
And even that implies that hildon-meta is removed
belcher has quit [Ping timeout: 250 seconds]
<Wizzup>
what is the verbose tree / error?
<parazyd>
bbl I have to work on other things
<parazyd>
Wizzup: I advise to try it with a new image
<parazyd>
I outlined the steps to you and uvos earlier
<parazyd>
(See the sprunge)
<Wizzup>
yes, I wanted to offer help not pick up the task ;)
<parazyd>
I don't know how to solve it
<parazyd>
So somebody does have to pick it up
<crab>
hi again, what is the current kernel version i should be running on n900 assuming im up to date?
<crab>
is it > 5.1.21 ?
<Wizzup>
no, it is 5.1.21 until we finish the 5.15 upgrade path
<Wizzup>
I am going to try to do that today on my n900
<crab>
aah cool.
<crab>
thanks
<crab>
i was just wondering if the reason my gui doesnt work is maybe because im installed on an sd card
<crab>
and kernel wasnt getting updated somehow, but it seems like it is in that case. :)
<uvos>
Certificate verification failed: The certificate is NOT trusted. The certificate chain uses expired certificate. Could not handshake: Error in the certificate verification. [IP: 152.228.204.144 443]
<uvos>
whats wrong here
<uvos>
the oldstable change?
<uvos>
(upgrading a old bionic to latest devel)
<uvos>
ah was my fault
<Wizzup>
time?
<uvos>
yes
<uvos>
i saw 2021 in date and thoght that ment ntp worked
<uvos>
but i forgot fake-hwclock exists
<freemangordon>
Wizzup: hmm, I think I know what happens
<freemangordon>
it was build against ti434x I guess
<freemangordon>
so, I think ddx should have dependency to ti434x removed during build and a manual dependency to ddk-sgx-um virtual package
<freemangordon>
or ddk-sgx-um-libs or whatever the package is called
<Wizzup>
how would do we that in the ci
<Wizzup>
freemangordon: btw, how do you boot your 5.15 n900 kernel image?
<Wizzup>
any specific boot args?
<Wizzup>
I have the serial here but no lab power supply, so I can't check serial for another two weeks :D
<bencoh>
nah, who needs a lab psu anyway ... just rip open a usb cable and add a voltage divider with two resistors :*
<bencoh>
(mostly kidding ... but it would probably work)
<Wizzup>
maybe the kernel I built just doesn't work for the n900
<uvos>
parazyd style upgrade works fine on bionic
<uvos>
and the new ddk setup works fine on bionic in general
<Wizzup>
great
<Wizzup>
weird that if hildon-meta-droid4 depends on libegl1 (with specific ersion) it still does not get installed
<freemangordon>
Wizzup: I used uImage
<freemangordon>
Wizzup: why CI? debian packaging should be fixed to exclude ti434x frompackage dependencies
<freemangordon>
and in debian/control a manual dependency to virtual package shall be added
<freemangordon>
or just shlibs:Depends can be removed, but that's too drastic IMO
<freemangordon>
lemme see if I can fix the packaging
<Wizzup>
freemangordon: isn't that what I did?
<Wizzup>
freemangordon: ok thanks
<freemangordon>
no idea, sorry, did you do something I missed?
<Wizzup>
freemangordon: ok, I can't get the zImage to boot on the n900
<Wizzup>
freemangordon: no, please just take a look
<freemangordon>
try uImage
<Wizzup>
yeah the ci doesn't build a uimage
<Wizzup>
but I'll make one
<freemangordon>
yeah
<freemangordon>
do you want me to provide mkimage command
<freemangordon>
I mean - the paramters
<Wizzup>
I think it is this mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -d zImage uImage
<Wizzup>
but that's just what's in my history :)
<Wizzup>
let me check n9xx-linux
<freemangordon>
mkimage -A arm -O linux -T kernel -C none -a 80008000 -e 80008000 -n zImage -d zImage uImage
<freemangordon>
-n can be different/missing ofc
<Wizzup>
yeah
<freemangordon>
Wizzup: what is the virtual package name?
<freemangordon>
found it sgx-ddk-um-libs
<Wizzup>
freemangordon: right
<Wizzup>
and they both 'provide' it
<freemangordon>
ah, it is already a dependency
* freemangordon
did some mogic, lets see if it is going to work
<freemangordon>
but i guess if you copy it from d4 it will work
<Wizzup>
we have none at d4
<Wizzup>
[ 1032.943] (EE) AIGLX error: dlopen of /usr/lib/arm-linux-gnueabihf/dri/omap_dri.so failed (/usr/lib/arm-linux-gnueabihf/dri/omap_dri.so: cannot open shared object file: No such file or directory)
<Wizzup>
mesa eh
<Wizzup>
weird, even with the env var it doesn't work
<Wizzup>
time to compare versions
<freemangordon>
how's that (none on d4)?
<freemangordon>
how does it know it shoul dload omap and not modesetting?
<Wizzup>
I don't know, maybe I removed modesetting?
<freemangordon>
I am almost sure d4 has omap.conf
<ruleh>
there is /usr/share/X11/xorg.conf/99-omap.conf
<ruleh>
xorg.conf.d
<Wizzup>
ruleh: oh, yeah, I forget about these new paths... why do we have config in /usr/share again :-)
<ruleh>
I think it is supposed to be something like vendor supplied stuff goes to usr/share and admin configured stuff into etc or so
<Wizzup>
freemangordon: so it doesn't segfault for you as soon as you touch the screen ? :P
<Wizzup>
ruleh: right, yeah
<freemangordon>
no
<Wizzup>
I'll install debug symbols
Wikiwide_ has quit [Read error: Connection reset by peer]
<tmlind>
uvos: that pwrdm mismatch is a bit of a mystery, probably some glitch between the cpuidle and prm driver, harmless afaik
<freemangordon>
Wizzup: oh, now I remember, I increased CAM to 32 MiB :)
<freemangordon>
*CMA
<Wizzup>
hehe
<Wizzup>
ok
<Wizzup>
let me do that
<Wizzup>
any reason to make it even higher?
<freemangordon>
Wizzup: I don;t think we shall increase it that much
<Wizzup>
ok
<Wizzup>
rebuilding kernel
<freemangordon>
I have a kernel fix in mind, unfortunately Tomi refused to accept the idea
<uvos>
tmlind: ok, dont see it on d4
<Wizzup>
I think 32M is fine (for now)
<uvos>
tmlind: seams to apear all the time on my bionic
<uvos>
tmlind: dosent have any obvious negative effect yeah
<freemangordon>
tmlind: is there any negative effect of increasing CMA on n900?
<Wizzup>
uvos: ok questions are being asked internally about gitorious
<uvos>
thank you :)
<tmlind>
freemangordon: well how much does increasing help? n900 runs out of memory easily..
<freemangordon>
well, seems I didn't ask my question correctly :). Lemme rephrase - what should be the recommended value? given that we need at least 3 800x480x4 buffers for Xorg only
<tmlind>
not sure, sounds like some experiments are needed to find the usable minimum size
<freemangordon>
yeah. well, I'd rather write that fix
<tmlind>
sounds like no help increasing it beyond the necessary minimum?
<Wizzup>
uvos: they might hand me all the gitorious data and task me with putting it online, we'll see
ruleh has quit [Quit: Client closed]
<freemangordon>
but, I think we need contiguous memory for VRFB, so maybe that patch is not that helpful
<Wizzup>
fun...
<freemangordon>
*will not be that helpful
<freemangordon>
yeah: "...must be allocated as a contiguous memory segment."
ruleh has joined #maemo-leste
<tmlind>
maybe play with cma=size[MG] option a bit?
<freemangordon>
tmlind: well, no hurry, I am just thinking a bit
<freemangordon>
we need at lest 6MiB just for the framebuffers
<freemangordon>
but for others, I still think it makes sense to not use CMA
<calebtheythem[m]>
freemangordon: the bloody RTC on this thing is readonly
<Wizzup>
freemangordon: no keyboard though
<Wizzup>
iiuc
<calebtheythem[m]>
it reports the time since the battery was last removed (relative to epoch)
<Wizzup>
lol
<freemangordon>
and? you cannot set the date?
<calebtheythem[m]>
i guess some the lockscreen clock got confused
<calebtheythem[m]>
you can't write to the RTC
<sicelo>
iirc this is the fastest/most powerful phone that's mainlined
<freemangordon>
yeah, and is relatively new
<calebtheythem[m]>
in postmarketOS we have a script which "solves" this by storing the now-rtc offset and updating the time
<freemangordon>
2018
<Wizzup>
freemangordon: anything in particular that should be in powervr.ini ?
<uvos>
hildons gona fly on that
<freemangordon>
I imagine leste is liek butter on this
<uvos>
unfortionatly it dosent scale
<freemangordon>
Wizzup: we don;t need powervr.ini :)
<uvos>
so you need 7nm fingers to go with your 7nm process node
<freemangordon>
uvos: I think we can easily scale it
<uvos>
x can scale it
<Wizzup>
calebtheythem[m]: btw mce will disable input devices if the device is considered in 'locked' mode, but since it vibrated it shouldn't be locked
<uvos>
sure
<freemangordon>
it is clutter behind the scenes after all
<uvos>
Wizzup: trying to idle the keypad is a useless endeavor
<uvos>
Wizzup: the kernel holds any device with any KEY _watever event open for itself regardless
<Wizzup>
anyway I'm really going to take a break now
uvos has quit [Ping timeout: 245 seconds]
epilys has joined #maemo-leste
<epilys>
hello everyone
<epilys>
has rust been tried/run on maemo?
<dsc_>
most just went to bed before you came in I think :)
<epilys>
my irc bouncer will be here all night
missMyN900 has joined #maemo-leste
<missMyN900>
hi everyone - I used to own an N900 and now have a Pinephone (3 GB edition) with Maemo Leste on a microSD and postmarketOS Plasma on the eMMC