<sicelo>
please review and merge if acceptable :-)
doc|home has joined #maemo-leste
uvos__ has quit [Ping timeout: 255 seconds]
fab_ has joined #maemo-leste
pere has quit [Ping timeout: 255 seconds]
pere has joined #maemo-leste
<Wizzup>
yeah I guess we can use this code unconditionally now
xmn has quit [Ping timeout: 276 seconds]
uvos__ has joined #maemo-leste
<Wizzup>
sicelo: if it wasn't clear, I merged and built
yeiskomp has quit [Ping timeout: 246 seconds]
akossh has joined #maemo-leste
nahawand has joined #maemo-leste
akossh has quit [Ping timeout: 256 seconds]
uvos__ has quit [Ping timeout: 268 seconds]
akossh has joined #maemo-leste
<sicelo>
Yay! Thanks.
pere has quit [Ping timeout: 240 seconds]
pere has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
Wizzup: other than that you have to reopen whatever window with the drop down menu, sphone should have no problems with dynamicly added backends
<freemangordon>
guys, do we have any application that runs on n900 and requires 24bpp?
<freemangordon>
if not, I think it makes sense to default to 16bpp there
<uvos>
i mean given enough swap anything should run on n900
<uvos>
if you enjoy correspondence chess with your phone
<freemangordon>
well... pushing a button and waiting a minutes is not exactly "running"
<freemangordon>
I mean "runs properly"
fab_ has quit [Quit: fab_]
<freemangordon>
also, if anyone is missing some application, it can always switch to 24bpp
<freemangordon>
or fix the application :)
<Wizzup>
uvos: ah ok
<Wizzup>
freemangordon: fine by me @ 16bpp
<uvos>
but making the gui follow along with sphone core would be a valid improvement
<uvos>
im fine with it too for n900, dont think the tradeoff is sane on mapphones or faster devices
<freemangordon>
agree
<freemangordon>
but on n900 we are just torturing the device for no particular reason
<freemangordon>
on faster device I suspect we will gain almost nothing, perhaps 2% more battery life
<uvos>
at the very least composition is pretty memory intensive even at d4 scale (ie takes several mb with a couple of windows open)
<uvos>
16bpp helps with that
<uvos>
but anyhow
<freemangordon>
right
<freemangordon>
but I suspect we'll have issues with browsers and whatnot
<freemangordon>
I wonder if we somehow could cheat using composition
<freemangordon>
like, h-d can use 16bpp context
<freemangordon>
the others 24 or 32
<freemangordon>
but honestly, no idea how to achieve that
<freemangordon>
anyway, XV support in mafw is back, runtime detected with fallback XV->GLES2->GL
<uvos>
no way of doing that without majorly hacking xorg
<freemangordon>
with that (and 16bpp) even n900 is able to play 480p BBB with no issues in OMP
<uvos>
since h-d output buffer has to be in the depth of x and x will report its depth to all its clients
<freemangordon>
ok, but in theory you can request drawable that's in different depth, no?
<uvos>
sure, but you cant draw to the xwindow without conversion, theres an extension that allows x to do this but thats probubly really slow
<uvos>
you would be converting 32bits to 16 for h-d to do its rendering and then having x convert to 32 for output
<uvos>
thats maddness
<freemangordon>
but anyway we are doing blits through GPU
<uvos>
so i dont see how you could do this without poor performance atm
<freemangordon>
that'd do that conversion for free (I guess)
<freemangordon>
but yeah
<freemangordon>
not sure what the gain would be
<freemangordon>
2MB saved from scanout buffers?
<freemangordon>
makes no sense
<uvos>
a fun(ish) idea would be to have 2 xservers
<Wizzup>
I think we can just try 16bpp on n900 and if it turns out it's not feasible we flip it back
<freemangordon>
mhm
<uvos>
and vt switch for 32bit requireing apps
<Wizzup>
we don't -need- firefox to work anyway for example
<uvos>
firefox works
<uvos>
it just is slow in 16bit
<freemangordon>
no, it does not
<uvos>
(presumably dose conversion)
<uvos>
freemangordon: hmm it works here for sure (desktop)
<freemangordon>
heh
<freemangordon>
on n900
<uvos>
Xephyr :1 -ac -screen 800x600x16
<Wizzup>
uvos: or xpra maybe
<uvos>
run firefox on that
<uvos>
works
<uvos>
its really slow however
<freemangordon>
uvos: the least issue on n900 running FF would be the screen depth
<uvos>
freemangordon: sure
<uvos>
freemangordon: im just saying it works in 16 bit at least on llvmpipe
<uvos>
modesetting/llvmpipe
<freemangordon>
we can run it on d4 without llvmpipe
<uvos>
yes none of this is practical
<freemangordon>
mhm
<freemangordon>
but still, it is about n900
<uvos>
im just stateing 16bpp is not fundamentally broken in ff
<freemangordon>
Wizzup: did you create new config with powervr.ini?
<uvos>
firefox on Xephyr :1 -ac -screen 800x600x16 <- actually that no longer works
<uvos>
but remoteing firefox 78 on d4 to a 16bit xephyr works
<uvos>
so they broke this since
<uvos>
nice
<Wizzup>
freemangordon: yes
<Wizzup>
freemangordon: do you want me to pkg it?
<Wizzup>
or try powerv.d ?
<freemangordon>
yes, maybe powervr.d is better place
<freemangordon>
but that should be part of mapphone config, no?
<freemangordon>
no separate package
<freemangordon>
leste-config that is
<Wizzup>
leste-config-mapphone iirc
<Wizzup>
should I try and see if it also works when it is in powervr.d ?
<freemangordon>
yes, please
<freemangordon>
but name ti something like...dunno, ...
<freemangordon>
sgx545.ini or something
<freemangordon>
or mapphone.ini
<Wizzup>
so we still want this?
<Wizzup>
# cat hildon-desktop.ini
<Wizzup>
[hildon-desktop]
<freemangordon>
not sure what the format of the files in that directory is
<Wizzup>
WSEGL_UseHWSync=0
<freemangordon>
no
<freemangordon>
this is not used at all
<freemangordon>
WSXXX is gone long ago
<Wizzup>
maybe that's just a stray file on my phone :)
<freemangordon>
I think h-d installs it
<freemangordon>
Wizzup: so, for now I am done with multimedia stuff
<freemangordon>
OMP ha some glitches in video playback window, but I'll leave them to either me, when I want to play again with it, or someone else
<freemangordon>
issue is that background is not cleared properly in some cases
xmn has joined #maemo-leste
<freemangordon>
so, I'll give it a couple of days for bugs to appear and will move to stable (mafw, tracker, omp)
<freemangordon>
ok?
<Wizzup>
yes
<Wizzup>
I think with powervr.d/mapphone.ini it doesn't work
<Wizzup>
the corruption is back
<Wizzup>
so I guess we need powervr.ini
<freemangordon>
mhm
norayr has quit [Excess Flood]
<tmlind>
no ants so far, nice :)
xmn has quit [Ping timeout: 246 seconds]
xmn has joined #maemo-leste
lexik has quit [Ping timeout: 260 seconds]
lexik has joined #maemo-leste
xmn has quit [Ping timeout: 268 seconds]
xmn has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
freemangordon: happy you're convinced by 16bpp on n900 now :P
<arno11>
btw i tried an old img to compare with my main config and that's pretty similar in term of performances
<arno11>
btw light transitions have few/no effect on scrolling but a huge effect to open some menus or apps
<Wizzup>
still doesn't make sense to me
<arno11>
me too
<arno11>
maybe some animations are not working properly and slowing down some apps on startup ?
<arno11>
i think i should definitely make a video...
<Wizzup>
freemangordon: building leste-config for pwoervr.ini now
<bencoh>
silly question, but how transitions are supposed to affect scrolling?
<bencoh>
I mean, how do you test that part?
<bencoh>
you can't really scroll during transitions (?)
<arno11>
i mean there are not only transitions settings in transitions.ini
<bencoh>
ah, I see
<arno11>
and i think transitions.ini tweaks are just workarounds: the issue is probably elsewhere
<arno11>
but that's over my skills
<uvos>
tmlind: "uvos: does modprobe modprobe cpufreq-dt-platdev fix it for you?" <-- yes it dose
<uvos>
strange why is it not loaded on boot
<uvos>
tmlind: oh btw, i installed leste on a new d4 and discovered that https://github.com/tmlind/droid4-kexecboot/tree/master/2022-12-05 now has up + down on the kbd swapped to be left and right, which isent a problem but is a bit strange, was that on purpose?
k1r1t0_N900 has quit [Ping timeout: 255 seconds]
k1r1t0_N900 has joined #maemo-leste
<Wizzup>
uvos: depmod -a?
arno11 has left #maemo-leste [#maemo-leste]
<uvos>
Wizzup: i mean the kernel install performs a depmod
<Wizzup>
try it and see, when I did cross compiles I ran into that problem sometimes
<Wizzup>
I'm not saying it will fix it, but it very well might
akossh has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: so, is it possible to override default kbd backlight brightness without recompiling mce?
<freemangordon>
hmm: Dec 13 22:34:55 localhost alarmd[2766]: /dev/rtc0: open -> Permission denied
<uvos>
mapphone?
<freemangordon>
yes
<freemangordon>
d4
<uvos>
i presume alarmd wants to use the rtc to setup the rtc alam
<uvos>
so this is immaterial as the driver dose not support this feature
<Wizzup>
would that give perm errors or something else
<freemangordon>
ok, but it tries to open it every now and then
<freemangordon>
def it is perm error
<freemangordon>
it is root:root
<uvos>
openting the rtc should be fine
<uvos>
the ioctl should fail
<freemangordon>
open -> Permission denied
<freemangordon>
I don;t see how user can open deviice that is root:root 600
<Wizzup>
we can set up a udev rule for it
<freemangordon>
I think we shall
<uvos>
sure, this causes the error but fixing this wont do anything, just change the error and presumably cause alarmd to waste time
<freemangordon>
it already wastes time
<freemangordon>
also, d4 is not the only one with rtc clock
<freemangordon>
n9 has one as well
<freemangordon>
that supprts wake-up
<uvos>
i mean hw wise the d4 supports wake-up too
<uvos>
but sure
<freemangordon>
also, why do you think omap4 does not support rtc wake-up?
<uvos>
just make sure alarmd knows not to crash when its ioctl fails
<uvos>
freemangordon: its not omap4 its cpcap
<uvos>
and it supports it fine
<uvos>
its just the driver dosent
<freemangordon>
will fix it if it crashes
<freemangordon>
ok, we may want to implement support at some point
<freemangordon>
uvos: btw, how's your idle power usage after latest tracker fixes? back to normal?
<uvos>
dunno messing with the kernel rn
<Wizzup>
I think it is
<freemangordon>
Wizzup: shall I open an issue for that (rtc)?
<freemangordon>
or you will remember it
<Wizzup>
issue is better
<freemangordon>
I'd rather remember it and pester you from time to time :)
<Wizzup>
also fine
<freemangordon>
btw it seems on arch they change owner of rtc to root:audio 660
<Wizzup>
with the battery you made for me I get 2 days or battery life with no problem
<Wizzup>
with the tracker bug it was way less
<freemangordon>
great
<sicelo>
i wonder how 'audio' relates to rtc0 :p
<Wizzup>
freemangordon: btw I think the udev rule I would add would be mapphone specific
<Wizzup>
what I am understanding here is that you want leste in general to change /dev/rtc? perm bits
<freemangordon>
yes
<freemangordon>
because we have /dev/rtc on n900 as well, no?
k1r1t0_N900 has quit [Ping timeout: 260 seconds]
<freemangordon>
why it should be mapphone specific only?
ceene has quit [Ping timeout: 256 seconds]
akossh has joined #maemo-leste
akossh has quit [Ping timeout: 256 seconds]
<Wizzup>
freemangordon: shouldn't be, I just didn't know the perm problem existed everywhere
akossh has joined #maemo-leste
<uvos>
so anyone know how to activate the freqencies in scaling_boost_frequencies enable?
<uvos>
so the only writeable sysfs files i have are scaling_max_freq scaling_min_freq and scaling_setspeed
<uvos>
writeing something from scaling_boost_frequencies into scaling_max_freq wold be the obvious aproch but this dosent work for freqencies not listed in scaling_available_frequencies which dosent include boost
arno11 has joined #maemo-leste
<arno11>
uvos: when boost freqs are added in dts, a new boost folder appears in /sys/devices/system/cpu/cpufreq/
<arno11>
*boost file
<uvos>
ok yeah
<uvos>
and writeing there insta hanged by device
<uvos>
so i gues it works
<Wizzup>
depending on what you write :D
<uvos>
do you know how to select which boost freqencies become avialble?
<arno11>
just set boost to 1 and boost freqs are automatically available
<arno11>
and then you can set max freq
<uvos>
hmm but just writeing a 1 there hanged my device
<uvos>
i never got to the later part
<arno11>
ah
<uvos>
oh well
<uvos>
i gues it works
<uvos>
this n900 just dosent like anything over regular clocks
<arno11>
ah ok
<uvos>
lemmy try mapphone
akossh has quit [Ping timeout: 260 seconds]
<uvos>
seams to work
<arno11>
cool
<uvos>
but i was only able to achive a minimal overclock 1.3ghz, vs my previous 1.4 ghz overclock via modifing the dts
<uvos>
so thats a bit wierd
<uvos>
anyhow
<uvos>
lemmy merge in .67 and do a release
<arno11>
maybe the voltage is a bit different ?
<uvos>
should be unchanged voltage from 1.2ghz in both cases