panzeroceania has quit [Read error: Connection reset by peer]
panzeroceania has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
parazyd: yeah so the card0 card1 thing is a bug in sdl thats fixed later
<uvos>
parazyd: but there is another problem
<uvos>
parazyd: fixing that sdl will still segfault on ddk1.9 most of the time
<parazyd>
:o
<uvos>
parazyd: on ddk1.17 it works
<uvos>
so im just gona pivot and start an xserver for it
<uvos>
for now
<parazyd>
That works?
<uvos>
parazyd: yeah sure
<parazyd>
ok
<parazyd>
So we'd maintain another nested minimal rootfs?
<uvos>
parazyd: no why
<parazyd>
ah nvm, I was thinking you wanted to do some separate root. But yeah, ok, it's possible to just do it from a runlevel.
<parazyd>
(I'm understanding "pivot" as pivot_root)
<uvos>
parazyd: ah ok
<uvos>
yeah
<parazyd>
Is the working sdl2 version tagged in their scm?
<parazyd>
I can ideally just merge it
<uvos>
parazyd: idk what commit is is exactly
<uvos>
parazyd: they refactored the kms code
<uvos>
parazyd: inbetween
<parazyd>
Let me see what's the latet
<uvos>
parazyd: so rn i have a runlevel checks if the device is charging that starts a kmsdrm application that displays the charging animation. when that quits (due to user input or an alarm or charging being discconected) the device will switch to default or power down depending
<uvos>
and this works on my ddk1.17 install
<parazyd>
hm, no tag
<uvos>
on leste i can just start an xserver and display the animation there
<parazyd>
Sounds good
<parazyd>
btw can we have coexisting pvr blobs?
<parazyd>
Both 1.9 and 1.17?
<uvos>
no
<uvos>
or maybe
<parazyd>
This might be a good time to package something
<parazyd>
But currently they always end up in the default runlevel due to the internals of insserv & friends
<parazyd>
So in postinst you remove it from the default runlevel and add it to another one
<uvos>
ok
<parazyd>
What would you then prefer for the animation? Some kind of SDL + 1.17 or direct FB + 1.9 ?
<uvos>
parazyd: also directfb + sdl could be tryed
<uvos>
that might be best
<uvos>
as we can switch to kms with 1.17
<uvos>
with ease
<parazyd>
Provided new sdl breaks on 1.9, this is not super-trivial to solve, but I think we could just compile an additional sdl2 to just be used by the animation
<parazyd>
And basically we could only compile the kms backend
<uvos>
parazyd: i dont get it
<uvos>
parazyd: compiling sdl2 with the directfb backend should be enough
<uvos>
if it works
<uvos>
on 1.9
<parazyd>
You said newest SDL2 segfaults generally on 1.9
<uvos>
parazyd: no the kms backend dose
<parazyd>
You didn't mean system-wide?
<parazyd>
ahhh
<uvos>
no
<uvos>
x11 backend
<uvos>
and works fine
<uvos>
and fb idk
<parazyd>
Ok that's different than what I understood
<uvos>
sorry
<uvos>
so on 1.9 we can just use x11 or fb
<parazyd>
np
<parazyd>
So
<parazyd>
What I can do: Compile latest libsdl as-is, plus enable video-directfb
<parazyd>
Would that be enough?
<uvos>
yeah
<uvos>
yeah
<parazyd>
And can kmsdrm stay or should it be disabled?
<uvos>
disable is better for now
<parazyd>
ok
<uvos>
but we can select a backend with an envvar
<uvos>
so it can stay if you prefer
<uvos>
otherwise sdl will use kms first
<uvos>
(and segfault)
<parazyd>
Let's see if it builds...
<parazyd>
I disabled kmsdrm for now
<parazyd>
(It'll take some minutes to build)
<parazyd>
uvos: btw you mentioned pvrsrvinit should go to sysinit. Does your runlevel inherit sysinit then?
<parazyd>
uvos: I don't understand why it would be necessary to make the change, if pvrsrvinit can just be part of your new runlevel
<uvos>
parazyd: well pvrsrvinit must not run twice
<uvos>
parazyd: and we cant ensure that the new runlevel runs at all
<uvos>
parazyd: since we cant change boot.conf
<uvos>
parazyd: my runlevel dosent inheret sysinit
<uvos>
parazyd: but afaik it allways runs anyhow
<uvos>
parazyd: at least thats what happens rn on my device
<parazyd>
ok, I guess we can try
<parazyd>
well, X might depend on it
<parazyd>
So perhaps that's why
<uvos>
not
<parazyd>
ANyway, ok. I'll move it to sysinit as that won't hurt
<uvos>
no
<uvos>
pvrsrvinit runs before the default runlevel
<uvos>
its allready fired when my charging runlevel gets started
<uvos>
(by changing the kernel command line to to start that runlevel)
<uvos>
parazyd: you dont by any chance know why this bash -c "/bin/false; /bin/echo $?" outputs 0 do you?
<parazyd>
hah no
<parazyd>
But bash -c "/bin/false || /bin/echo $?" gives 1
<parazyd>
oh no
<parazyd>
wtf
<uvos>
yeah
<parazyd>
I run it multiple times and it's random
<uvos>
uh-oh
<uvos>
allways 0 for me
<parazyd>
ah
<parazyd>
It's because of the parent shell it seems
<parazyd>
Use single quotes: '
<parazyd>
$? expands in ""
<parazyd>
So: bash -c '/bin/false ; /bin/echo $?'
<uvos>
ah
<uvos>
makes sense
<uvos>
thanks
<parazyd>
yw
<parazyd>
note-to-self: pvrsrvinit also for N900
<parazyd>
Setting up pvr-omap4 (1.9.0.8.1.3-1+2m7.4) ...
<parazyd>
* service pvr-omap4 removed from runlevel default
<parazyd>
* service pvr-omap4 added to runlevel sysinit
<parazyd>
This is done
<parazyd>
uvos: SDL with directfb built in -devel
<uvos>
great
<Wizzup>
directfb still exists?
<Wizzup>
brings back memories
<parazyd>
Wizzup: Yeah, though Debian disabled it in their SDL package
<parazyd>
I suppose to the benefit/choice of kmsdrm
<parazyd>
The nfs stuff could just be removed from all runlevels
<parazyd>
mountnfs.sh
<uvos>
why do we need the hildon-env-setup envvars at this point?
<uvos>
why do we need fake-hwclock at all?
<uvos>
all of our targest have real hwclocks no?
<parazyd>
RaspberryPi and similar don't
<uvos>
ok but fake-hwclock is damaging on the devices that do no?
<uvos>
since system time will be wrong for a while
<uvos>
causeing some warps
<parazyd>
Perhaps, yeah
<parazyd>
hildon-env-setup can be moved to default too
<parazyd>
I just need to see which initscripts should be in "before"
<parazyd>
uvos: btw charge-mode should somehow first check if charging is happening before doing any other stuff. The xinit is too cumbersome, and I assume the same is with directfb.
<parazyd>
uvos: There should be a check first and then act either to default runlevel or start the animation
<uvos>
parazyd: it checks first and then inits the video mode
<uvos>
parazyd: in kms or directfb this works perfectly
<uvos>
parazyd: obviously x needs to be started before it executes
<uvos>
parazyd: so works fine everywhere except x
<parazyd>
ok, yeah
<parazyd>
Then let's definitely drop X here
<uvos>
sure as soon as something else works ;0
<uvos>
*;)
<parazyd>
ok, updating hildon-base for the initscript that can live in default
<parazyd>
Skipping a few of these initscript should make it faster in theory
<parazyd>
Seems a tad better
<parazyd>
Funny to see X start->stop->start
<uvos>
/boot/boot/boot.cfg not being in a package bites us here too
<uvos>
(not sure how you intend to deploy this)
<parazyd>
Will think about it
<parazyd>
We could go barbarian and just overwrite it
<parazyd>
(And make a backup)
<uvos>
break any device where leste is installed to internal storage
<uvos>
idk if anyone but me dose that
<parazyd>
Probably not
<tmlind>
uvos: hey cool charge mode, nice :)
<tmlind>
uvos: i too had one failure booting with charger connected, i wonder if it's because of sysrq is enabled until sysctl.conf loads
pere has quit [Ping timeout: 245 seconds]
inky has quit [Ping timeout: 252 seconds]
inky has joined #maemo-leste
pere has joined #maemo-leste
inky has quit [Read error: Connection reset by peer]
inky has joined #maemo-leste
xmn has joined #maemo-leste
<uvos>
tmlind: good idea
inky has quit [Ping timeout: 260 seconds]
inky has joined #maemo-leste
xes_ has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
inky has quit [Ping timeout: 260 seconds]
inky has joined #maemo-leste
cockroach has joined #maemo-leste
ravelo has quit [Quit: Connection closed for inactivity]