| kiva | Kernel 6.6 in stable sdcard-image when? For xmas? | 13:04 |
|---|---|---|
| Wizzup | which device? | 13:05 |
| kiva | Pinephone? | 13:06 |
| uvos__ | currently as far as i am aware we lack a maintainer for the pinephone kernel | 13:09 |
| uvos__ | the omap devices are all on 6.6 already | 13:09 |
| kiva | Has droid4 sdcard image in here it: https://maedevu.maemo.org/images/droid4/ | 13:10 |
| uvos__ | no you would have to update to devel after installing | 13:12 |
| uvos__ | but promoting this is something that should happen very soon | 13:13 |
| uvos__ | the pinephone on the other hand needs someone to rebase the kernel, or maybe just steal a never kernel from pmos or something | 13:14 |
| uvos__ | btw you can check here | 13:14 |
| uvos__ | https://maedevu.maemo.org/pkgweb/search?q=linux | 13:14 |
| Wizzup | yes, I think rafael2k has been busy | 13:14 |
| Wizzup | we also should make the pinephone pro work | 13:14 |
| uvos__ | the images contain Packages found in chimaera: | 13:14 |
| Wizzup | someone made it work and then left I think | 13:14 |
| uvos__ | devel has Packages found in chimaera-devel: | 13:15 |
| uvos__ | Wizzup: maybe promote the kernel soon? i thought you did already | 13:15 |
| uvos__ | are there any outstanding issues im not aware of? | 13:15 |
| Wizzup | uvos__: let's do it | 13:22 |
| Wizzup | I have been working 16 hour days sinxe oct 10 or so | 13:22 |
| Wizzup | including weekends, so I had no time/energy | 13:22 |
| Wizzup | but it's getting better now | 13:22 |
| uvos__ | Wizzup: great! | 13:23 |
| xmn | That is tough Wizzup. Hopefully it continues to ease up back to normal. | 13:24 |
| arno11 | Wizzup: btw if you promote 6.6 and build new imgs, hope gconf2 and dbus errors we got in last stable imgs (when upgrading to devel) disappear. | 14:30 |
| Wizzup | I think those errors appeared only once, no? | 14:31 |
| arno11 | not sure what happened | 14:31 |
| arno11 | last time i tried a recent img it was really buggy | 14:32 |
| arno11 | but i don't remember exactly | 14:32 |
| arno11 | it happens to sicelo as well iirc | 14:33 |
| arno11 | and to some guys from tmo | 14:33 |
| arno11 | *i mean, the gconf and dbus error | 14:34 |
| dsc_ | arno11: did you try this pidgin-chatgpt | 14:35 |
| arno11 | not yet, will try soon | 14:36 |
| arno11 | and let you know | 14:36 |
| arno11 | dsc_: the plugin itself works fine :) so it should be trivial to make it working in conversations | 14:55 |
| dsc_ | so ehh | 14:56 |
| arno11 | however, it works only for 4-5 requests then reset the chat apparently | 14:56 |
| dsc_ | idk anything about the pidgin stuff | 14:56 |
| arno11 | the plugin is a purple plugin | 14:56 |
| dsc_ | doesnt it not then automatically work via purple, yeah | 14:56 |
| arno11 | so it should work in converstions using mctool | 14:57 |
| dsc_ | ah ok | 14:57 |
| dsc_ | so it only needs the gtk dialog for API key | 14:57 |
| arno11 | yup | 14:57 |
| arno11 | i'll try to add it through mctool (but i maybe need a reboot) | 14:58 |
| arno11 | hmm i don't know which manager it uses | 15:10 |
| dsc_ | no idea | 15:19 |
| arno11 | anyway the plugin seems to have limited capacity in term of context saving (giving a kind of memory to chatgpt) | 16:13 |
| arno11 | after 4 or 5 requests, it only remembers the first one | 16:14 |
| arno11 | i don't encounter this problem in bash since i found a way to add as many contexts as i need | 16:22 |
| dsc_ | arno11: this project seems to be 1 week old | 16:28 |
| dsc_ | so maybe still in development | 16:28 |
| arno11 | yes indeed | 16:28 |
| freemangordon | Wizzup: I think I fixed osso-abook in regards to attribute names/ vcard field, however, it seems sphone abook plugin does a mess in rtcomel DB | 17:38 |
| Wizzup | hmm | 17:39 |
| freemangordon | will push to -devel later on | 17:39 |
| inky | > currently as far as i am aware we lack a maintainer for the pinephone kernel | 18:15 |
| inky | > | 18:15 |
| inky | > the omap devices are all on 6.6 already | 18:15 |
| inky | i built 6.11 on pinephone/gentoo so i can try to do the same for maemo. | 18:15 |
| inky | https://justsoup321.codeberg.page/posts/lomiri-the-final-frontier/ | 18:15 |
| inky | i guess hildon is easier to maintain, it stands alone, all or most of the services are started by xsession scripts. | 18:18 |
| arno11 | sicelo: btw something to improve @als/mce is the minimum level of backlight: a way too high on n900 (50% iirc). not ideal in the dark. 5-10% is enough imo. i personaly use 2% | 20:09 |
| arno11 | and it is not ideal for power draw | 20:11 |
| arno11 | and not progressive enough | 20:11 |
| uvos | arno11: you can configue the brighness levels vs lux values however you want in mce.ini | 20:18 |
| uvos | however the default is way lower than 50% | 20:18 |
| arno11 | ok for mce.ini but the minimum is really around 50% | 20:20 |
| sicelo | someone just shared (on telegram) a video of Leste running on xiaomi prime 4 with the pmOS kernel. it's SW rendered for now, but I guess they'll get GPU playing along soon | 20:20 |
| uvos | arno11: no its 20 | 20:20 |
| sicelo | what % are those BTW? | 20:20 |
| uvos | yes | 20:21 |
| uvos | note that mce never lowers the brigtness while the display is on | 20:21 |
| uvos | it only raises it | 20:21 |
| uvos | unless you set NoAlsLowering to 0 | 20:21 |
| arno11 | so i'm pretty sure something keeps minimum value too high. let me check again | 20:22 |
| sicelo | Anyway, my als aim was to extract the correct calibration from cal on the n900, which should hopefully result in more accurate lux readings | 20:22 |
| uvos | sicelo: ok | 20:22 |
| uvos | rn mce dose scale the als valuse | 20:22 |
| uvos | but really this isent mces job | 20:23 |
| uvos | sysfs has a scale file that udev reads, if you cant set the scale file correctly in dts you should set the udev proparty | 20:23 |
| uvos | iio-s-p then scales the sensor based on that | 20:24 |
| arno11 | uvos: i just doublecheck and default minimum real value is 51 | 20:24 |
| sicelo | iio-s-p doesn't really do justice to n900's als - it reports two separate channels, but iio-s-p, as a generalization application, tried to represent a | 20:24 |
| sicelo | all in one way | 20:24 |
| uvos | i cant parse that sentance | 20:24 |
| sicelo | mine or arno11 's? | 20:25 |
| uvos | yours | 20:25 |
| uvos | arno11: cover the sensor, check monitor-sensor to see that it reports 0 lux | 20:26 |
| uvos | click on the the lowest profile in the display settings app | 20:26 |
| uvos | turn off the display | 20:26 |
| uvos | turn on the display | 20:26 |
| arno11 | ok | 20:26 |
| sicelo | iio-s-p expects one sysfs node for the als. n900's als reports two - they work differently. hence you'll see in older mce code that there was calib0 and calib1 properties, for example | 20:27 |
| uvos | sicelo: ok what makes them different? | 20:27 |
| uvos | sicelo: different angles? | 20:27 |
| sicelo | the one is simply sensitive to normal light, and the other to light & ir | 20:28 |
| arno11 | uvos: it always report 0 | 20:28 |
| uvos | arno11: then its broken | 20:28 |
| sicelo | Anyway, I don't have time to work on it for the time being, but I think I can do something about it in future | 20:28 |
| uvos | this will indeed cause mce to use 50 | 20:28 |
| uvos | sicelo: anyhow if something needs to be fixed about it needs to be fixed in iio-s-p, mce is a consumer of the als data with no external sensor interfaces, so any other application needs the values to be correct too | 20:29 |
| uvos | i gues a iio-s-p maybe should read a composit of both values or something | 20:29 |
| uvos | sicelo: i presume your als works fine? | 20:29 |
| uvos | ie arno11 has hw failure? | 20:29 |
| sicelo | arno11, the als is working ... I'm guessing it's night there too, so yes lux reading will mostly be 0 | 20:29 |
| arno11 | ok | 20:30 |
| arno11 | let me try next to a light | 20:30 |
| arno11 | yes indeed it works | 20:31 |
| uvos | ok anyhow | 20:31 |
| uvos | if you do the above you should get 20% | 20:31 |
| uvos | if you dont i gues something is broken on your device | 20:31 |
| uvos | or n900 genrally | 20:31 |
| uvos | since it works fine on d4 | 20:31 |
| arno11 | default minimum value is still 51 | 20:32 |
| uvos | what do you mean by "default" | 20:32 |
| uvos | the lowest brightness profile ie 1 bar | 20:32 |
| uvos | is the one that should have 20% at zero lux | 20:32 |
| arno11 | with one bar it is 51% | 20:32 |
| uvos | when the display is turned on at 0 lux that is | 20:33 |
| uvos | where are you reading that from? | 20:33 |
| arno11 | there is a huge diff if i set it @20% by hand | 20:33 |
| arno11 | uvos: from /sys/class/backlight/acx565akm/brightness | 20:34 |
| uvos | ok | 20:34 |
| arno11 | *20% by hand @0 lux | 20:35 |
| uvos | ?? if you set it by hand obv the lux wont matter | 20:35 |
| arno11 | so something seems wrong on leste n900 in general, fremantle backlight is fine on my device | 20:35 |
| arno11 | uvos: yes indeed | 20:36 |
| uvos | anyhow i gues it could be broken somehow, maybe sicleo can confirm it | 20:36 |
| arno11 | yes maybe | 20:36 |
| uvos | i think mce prints what it sets the brigtness too | 20:36 |
| uvos | if you run it with -v -v | 20:36 |
| uvos | ie stop mce | 20:36 |
| uvos | and then start it as root (sudo su -) | 20:36 |
| uvos | with mce -v -v | 20:36 |
| uvos | and see what it prints when you switch brigness profiles | 20:37 |
| uvos | and change the lux | 20:37 |
| arno11 | ok | 20:37 |
| uvos | turning off no als lowering will help with debuging | 20:37 |
| uvos | since the brigness will then directly follow lux | 20:37 |
| sicelo | arno11: on fremantle it's using the full capabilities of the als. iio-s-p somewhat averages the separate results into one, so yeah, the behavior will not be comparable. plus fremantle uses proper calibration values (I assume, measure somehow from factory ' haven't yet tested if the calibration values are similar across devices, although I doubt) | 20:38 |
| uvos | sicelo: dosnet matter | 20:38 |
| uvos | if he sees 0 lux it should choose the lowest level | 20:38 |
| uvos | the sensor reading is not the issue here | 20:39 |
| uvos | sicelo: droid4 android has its callibration values fixed in dts | 20:39 |
| sicelo | I'm not necessarily answering the particular % stuff (I don't even know where the % being referred to are found) :-D | 20:39 |
| uvos | i dont think theres mutch variation really | 20:39 |
| uvos | oh wait | 20:40 |
| uvos | arno11: its fine | 20:40 |
| uvos | your reading /sys/class/backlight/acx565akm/brightness | 20:40 |
| uvos | thats wrong | 20:40 |
| uvos | /sys/class/backlight/acx565akm/brightness is not in % | 20:40 |
| uvos | its some arbitary value | 20:40 |
| uvos | how you scale the value to get % is given by the other sysfs files | 20:41 |
| uvos | (brigtness_steps or so iirc) | 20:41 |
| sicelo | 20/255 | 20:41 |
| uvos | on d4 its out of 16 | 20:41 |
| uvos | anyhow 51/255 = 0.2 | 20:41 |
| uvos | so its working exactly as intended | 20:41 |
| uvos | if thats to bright for you just change the values in mce.ini | 20:42 |
| uvos | those ARE in % | 20:42 |
| arno11 | ok | 20:42 |
| arno11 | but yeah a way to high for me :P | 20:42 |
| uvos | if there is some consensus that its way to high we can change it in n900's specific mce.ini | 20:43 |
| uvos | mce.ini.d/SOMETHING-n900.ini | 20:43 |
| uvos | otherwise this is working as intenden | 20:43 |
| uvos | d | 20:43 |
| arno11 | ok | 20:43 |
| uvos | if 20 in /sys/class/backlight/acx565akm/brightness you should set the lowest brightness in your 99-user.ini to 8 | 20:44 |
| uvos | *if 20 is what you like | 20:45 |
| arno11 | ok thx | 20:45 |
| sicelo | arno11: BTW with fremantle you use kernel-power or the vanilla Nokia kernel? | 21:18 |
| arno11 | sicelo: i use kernel power 53 | 21:23 |
| arno11 | working fine @1GHz :P | 21:23 |
| sicelo | :-) | 21:24 |
| arno11 | btw opera mini still works fine on it, wonder if it could not be the solution for leste | 21:25 |
| arno11 | at least a usable solution | 21:25 |
| arno11 | for n900 ofc | 21:26 |
| arno11 | but it needs phoneME to work well | 21:26 |
| arno11 | not foss iirc | 21:27 |
| sicelo | mmm. it isn't? | 21:30 |
| sicelo | there's some j2me thing that should presumably work on modern linux. Will see if I still have its url. never tried it though | 21:30 |
| arno11 | we can use microemulator but it is a way slower than phoneME | 21:34 |
| arno11 | iirc opera mini works with microemulator but it is not user-friendly an slow on n900 | 21:36 |
| arno11 | with phoneME on fremantle, even google streetview works fine | 21:36 |
| arno11 | *btw | 21:36 |
| arno11 | ah, i remember now: phoneME is still on gh but difficult to compile (at least for me) | 21:40 |
| sicelo | there's something else besides microemulator. maybe freej2me? | 21:41 |
| * sicelo turns PC on to see what it was | 21:41 | |
| arno11 | ok | 21:41 |
| arno11 | freej2me works only for games iirc | 21:43 |
| sicelo | ah | 21:46 |
| arno11 | https://github.com/magicus/phoneME | 21:52 |
| sicelo | went back to dailying my D4 since the weekend. experienced https://github.com/maemo-leste/bugtracker/issues/753, which i don't think is PEBKAC | 22:27 |
| sicelo | looks like sphone should use the services of hildon-plugins-notify-sv perhaps? or profiled ... | 22:28 |
| uvos | sicelo: no | 22:39 |
| uvos | this is simply unimplemented | 22:39 |
| uvos | we have no "rining" volume | 22:39 |
| uvos | the setting in profiled goes no where | 22:39 |
| uvos | the correct sollution is to have ucm role for this (and alarm) | 22:39 |
| uvos | on fremantle there is a special sink that is used for this | 22:40 |
| uvos | again essentally the same thing as a ucm profile achived though different means | 22:40 |
| uvos | but yeah this has nothing to do with sphone per say | 22:41 |
| sicelo | sure, doesn't matter to me how exactly it's implemented (i think the one in profile goes through nsv from a quick check) ... anyway, the problem is real and *some* solution would be appreciated | 22:42 |
| uvos | nsv reads it | 22:42 |
| uvos | but its pointless | 22:42 |
| uvos | as it just outputs though the regular hifi sink | 22:42 |
| uvos | which could be muted or whatever | 22:42 |
| sicelo | https://github.com/maemo-leste/hildon-plugins-notify-sv/blob/master/lib/ringtone.c#L62 | 22:44 |
| sicelo | looks to me Like it actually does set a volume | 22:44 |
| uvos | yes, but as metioned this is pointless | 22:44 |
| sicelo | no idea what you mean. anyway, my point is - as things stand currently, it's easy to miss calls Unintentionally. i don't particularly care about profile or nsv per se, but just saying reducing media playback volume should not also reduce ringing volume. | 22:46 |
| uvos | sure | 22:46 |
| uvos | thats not question | 22:47 |
| uvos | but the audio setup is not to the point where this is possible | 22:47 |
| uvos | we need to do more pa work for it to happen | 22:47 |
| inky | sicelo, how do you feel daily using it? | 23:25 |
| inky | i do it but without phone calls, and with pidgin and email. | 23:25 |
| sicelo | it's fine. it's not the first time i daily it ... just I need a battery. only gripe i have is non-working USSD. | 23:36 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!