inky has quit [Ping timeout: 260 seconds]
uvos__ has quit [Ping timeout: 256 seconds]
uvos__ has joined #maemo-leste
joerg has quit [Ping timeout: 264 seconds]
joerg has joined #maemo-leste
fab_ has joined #maemo-leste
ceene has joined #maemo-leste
slep has joined #maemo-leste
doc has quit [Quit: Things to do]
fab_ has quit [Quit: fab_]
k1r1t0_N900 has joined #maemo-leste
<sicelo> Wizzup: another PR for gps-nokia-n900 ... https://github.com/maemo-leste/gps-nokia-n900/pull/2
<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> excepting touch screen responsiveness
<arno11> *(main config: 16bpp, boost freq off, light trans, new ddx, u3 card)
<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?
xmn has quit [Quit: ZZZzzz…]
<uvos> freemangordon: yes
<freemangordon> how?
<freemangordon> thanks
xmn has joined #maemo-leste
<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
<arno11> ok
<uvos> so not sure rn
<uvos> but anyhow
<uvos> it works in principal
akossh has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]