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