| sicelo | https://github.com/maemo-leste-extras/simple-brightness-applet ... just needs to be imported to daedalus. want to give that a go? :-) | 00:00 |
|---|---|---|
| dsc_ | I'd like to register Qt widgets in the status bar | 00:00 |
| dsc_ | that would be nice ;p | 00:00 |
| sicelo | e.g. widget for what functionality? | 00:00 |
| dsc_ | oh, just for whatever custom thing I personally want to build (not for inclusion into maemo) | 00:02 |
| dsc_ | well, perhaps a weather status widget | 00:02 |
| sicelo | although i think atm all widgets (status and desktop) are gtk | 00:03 |
| kiva14 | Is there any "hello world" programming tutorials for widgets? | 00:05 |
| sicelo | there should be, on wiki.maemo.org | 00:06 |
| sicelo | https://wiki.maemo.org/Using_Fremantle_widgets | 00:07 |
| kiva14 | thanks..I found also this: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Application_Development/Writing_Desktop_Widgets | 00:17 |
| kiva14 | this is not related to widgets, but there is real "hello world" for Maemo 4.x: http://maemo.org/maemo_training_material/maemo4.x/html/maemo_Getting_Started_Chinook/Chapter_03_Testing_the_installation.html | 00:30 |
| kiva14 | It would be nice that have for Maemo Leste to lower starting to Leste programing. | 00:32 |
| dsc_ | I debugged mce, it actually ranges from 624 to 3124 | 00:35 |
| dsc_ | but the fade is quite slow, so I assumed it was not working | 00:35 |
| kiva14 | fade is slow, because as you see in source it change with -1. | 00:37 |
| dsc_ | kiva14: ? :P | 00:38 |
| kiva14 | look under where was that something * something /100 (if I looked right when somebody put link about it. | 00:40 |
| dsc_ | I put a breakpoint here: https://git.maemo.org/leste/mce/src/branch/master/src/modules/display.c#L259 | 00:41 |
| dsc_ | new_brightness = 624 - 3124 (depending on what you clicked in the GUI) | 00:41 |
| dsc_ | it goes into the fade: https://git.maemo.org/leste/mce/src/branch/master/src/modules/display.c#L168 | 00:41 |
| dsc_ | which seems to be 10 seconds? | 00:41 |
| dsc_ | testing it now | 00:42 |
| kiva14 | line 249 | 00:42 |
| kiva14 | I am not c++ programmer, but if I can read that code, that makes fadings from old value to new | 00:43 |
| dsc_ | looks like an early exit to not fade twice with the same value? | 00:43 |
| kiva14 | ah you are right | 00:44 |
| kiva14 | Pinephone might have hardware fading. | 00:48 |
| kiva14 | or maybe not..line 187 : brightness_fade_steplength = 2; | 00:49 |
| dsc_ | step_time is the timeout for a callback (a function call) https://git.maemo.org/leste/mce/src/branch/master/src/modules/display.c#L156 | 00:49 |
| dsc_ | which then writes to a file https://git.maemo.org/leste/mce/src/branch/master/src/modules/display.c#L124 | 00:50 |
| dsc_ | so when our step_time is 10 | 00:50 |
| dsc_ | and we have 4 steps to go from 1 to 4 | 00:50 |
| dsc_ | it takes 40 seconds? | 00:50 |
| dsc_ | to fade | 00:50 |
| dsc_ | probably not | 00:50 |
| dsc_ | idk, im just looking how this works | 00:50 |
| dsc_ | well, 3 steps in that case | 00:51 |
| dsc_ | g_timeout_add(interval | 00:52 |
| dsc_ | "The interval given is in terms of monotonic time, not wall clock time. See g_get_monotonic_time()." | 00:52 |
| dsc_ | ?? | 00:52 |
| dsc_ | thx glib | 00:52 |
| sicelo | mce supports hardware fading only on the N900 | 00:54 |
| kiva14 | actually that fading time is not problem, because if steps for Pinephone would be 1, 800, 1600, 2400 and 3124 then change is more visible. | 00:55 |
| sicelo | scratch that ... this is not LED :-) | 00:56 |
| * sicelo should been long asleep anyway | 00:57 | |
| dsc_ | yeah, it just writes to /sys/class/backlight/backlight/brightness | 00:57 |
| dsc_ | but it does so too slow | 00:57 |
| Wizzup | yeah the steps seem to be the problem no? | 00:58 |
| dsc_ | yes | 00:59 |
| kiva14 | no if write to sys/class/ 3124 and then 1 it change instantly. | 01:00 |
| dsc_ | I have step_time "1" now, its faster, but I want to understand what it is :D | 01:00 |
| dsc_ | its the interval to g_timeout_add | 01:00 |
| dsc_ | but I dont think its milliseconds | 01:00 |
| dsc_ | anyway | 01:00 |
| sicelo | another solution would be to define the steps in an mce key, since, after all, there may be devices where the linearity (or visibility) of the change cannot be expressed in an easy formula (e.g. 20%, as we seem to have it) | 01:01 |
| dsc_ | yeah | 01:01 |
| sicelo | timeout_add is ms | 01:02 |
| kiva14 | if ask me Pinephone does not have linear brigness value. | 01:03 |
| dsc_ | ok ye | 01:03 |
| sicelo | linear wasn't the correct word actually, but my English fails me :-) | 01:03 |
| kiva14 | :) | 01:04 |
| dsc_ | with step_time=1, from step 1 (brightness 624) it executed that callback 1251 times, and 624+(1251*2) = 3126 | 01:04 |
| dsc_ | (from step 1 to full brightness) | 01:04 |
| dsc_ | and thats correct because | 01:05 |
| dsc_ | static gint brightness_fade_steplength = 2; | 01:05 |
| dsc_ | k | 01:05 |
| Wizzup | sicelo: too bad mainline doesn't offer another more simple interface | 01:05 |
| dsc_ | ahh ok, so the step length should be dynamic/related to the overall size | 01:07 |
| dsc_ | then we'll fix it, regardless of step_time | 01:07 |
| dsc_ | because I dont like firing a function every 1ms | 01:07 |
| Wizzup | it's non-linear | 01:07 |
| dsc_ | but like sicelo said, maybe better to hardcode some stuff | 01:07 |
| kiva14 | But anyway we (who we?) should only change step1 value from 624 to 1...get full brightness control. Value one is enough bright. | 01:08 |
| dsc_ | yeah but going from 624 to 3126 is not linear, im just talking about fixing the duration bug | 01:08 |
| dsc_ | i mean | 01:08 |
| dsc_ | ok this is becoming chaotic | 01:09 |
| dsc_ | but what I mean is, going from 624 to 3126 is linear | 01:09 |
| Wizzup | has anyone tried using brightnessctl? | 01:09 |
| Wizzup | brightnessctl s 40% (or whatever) seems to do the right thing | 01:09 |
| sicelo | on maemo? no. i use it on my laptop | 01:09 |
| Wizzup | it's available in daedalus | 01:09 |
| Wizzup | could we just call it for 20/40/60/80/100% ? :D | 01:10 |
| dsc_ | easy fix is making step length take into account the overall size of the total length | 01:10 |
| sicelo | i am not fully sure yet what's the problem with what we already have btw, haha. we calculate the values wrong? or the issue is the fading? | 01:10 |
| kiva14 | but 1/40/60/80/100 would be better. | 01:10 |
| Wizzup | dsc_: that doesn't work with non-linear doesn't it? | 01:11 |
| dsc_ | Wizzup: there is a callback (function call) which increments a number to a target value, the bigger the number, the longer it takes to get there (because the increments are static (2)) | 01:11 |
| sicelo | kiva14: it's not so simple. some devices may have a very big difference in brightness for that 40% :-) | 01:11 |
| dsc_ | I can make it call the function more often (decrease step_time) but this is a hack | 01:11 |
| Wizzup | ok yeah whatever the smooth thing is should just never run for more than a second | 01:12 |
| sicelo | e.g. Droid 4 max_brightness is 7 :-) | 01:12 |
| dsc_ | so the easy fix is to make the increments related to how big the change is | 01:12 |
| Wizzup | to me the bigger problem seems mce not supporting non-linear backlights | 01:12 |
| kiva14 | sicelo: conditional compile for Pinephone? Or 1/25/50/75/100? or more steps? | 01:13 |
| kiva14 | If ask me more steps. | 01:14 |
| sicelo | kiva14: that's why i think easiest/safest 'cheat' is a key in mce. it can be per device (leste-config-<device>). | 01:14 |
| dsc_ | do you have a droid, i'd like to see max_brightness there | 01:15 |
| sicelo | it's 7 :-) | 01:15 |
| dsc_ | I'm guessing its not a high number | 01:15 |
| dsc_ | right, thats why it goes fast there xD | 01:15 |
| kiva14 | sicelo: it would be good. And more steps ;) | 01:16 |
| sicelo | i totally agree that the increment shouldn't be static ... it should be derived from the whole range | 01:16 |
| sicelo | that way if the range is large, some values are skipped | 01:16 |
| dsc_ | right | 01:17 |
| dsc_ | ill change it | 01:17 |
| kiva14 | So if add one step to UI then Droid would have all values (I assume that 0 is off), one step more would be good also for Pinephone 1/20/40/60/80/100 | 01:22 |
| kiva14 | that was in persent, not real values. | 01:23 |
| dsc_ | if the increments are 2, and max brightness is 7 on droid, was it ever fully 100% :P | 01:35 |
| dsc_ | depends on the starting point I guess | 01:35 |
| dsc_ | https://git.maemo.org/leste/mce/pulls/66 | 02:11 |
| dsc_ | https://git.maemo.org/leste/status-area-applet-battery/pulls/11 | 02:19 |
| inky | kiva the app was fcamera. and it brought custom camera drivers. | 02:49 |
| freemangordon | Wizzup: https://github.com/cisco/libsrtp/pull/757 | 07:35 |
| kiva | dsc_: so six step with pre defined values and predefined fade value would one solution and another solution would be stepless bar and fade speed value calculated from how many values are for use. | 09:18 |
| kiva | inky: yes fcamera was that app. | 09:18 |
| sicelo | BlessN900 was also a thing, and worked the same way | 09:19 |
| kiva | Do I remember right Bless900 used fcamera driver? | 09:21 |
| sicelo | iirc yes | 09:21 |
| kiva | So Bless900 for Leste? | 09:23 |
| sicelo | the fcamera drivers are not available for use with mainline | 09:25 |
| kiva | but source is? | 09:26 |
| sicelo | dsc_: left review on the status-area-applet-battery MR | 10:20 |
| dsc_ | sicelo: ty | 10:51 |
| Wizzup | freemangordon: great, ty | 10:54 |
| dsc_ | my pinephone survived the night without power | 13:05 |
| dsc_ | from 90% to 20% | 13:05 |
| dsc_ | wifi disabled, with conversations | 13:05 |
| Wizzup | you can also use loginctl suspend to s2r | 13:17 |
| Wizzup | with the right setup the modem will wake it up if there is a call/sms, but we never tried to do that yet | 13:17 |
| dsc_ | Wizzup: preferably this suspend thing is an option in the dropdown menu that happens when you press the physical power button | 13:28 |
| dsc_ | however, since its all gtk I'm not particularly motivated to look at that | 13:29 |
| dsc_ | ill try suspend though | 13:29 |
| dsc_ | Wizzup: what email client do you use on Leste | 13:31 |
| Wizzup | modest, the built in | 13:33 |
| Wizzup | dsc_: no probably suspend would happen automatically once we have inhibitor locks or some kind | 13:33 |
| dsc_ | alright | 13:41 |
| freemangordon | dsc_: actually it is xml and dbus | 17:21 |
| freemangordon | dsc_: https://git.maemo.org/leste/osso-systemui-powerkeymenu/src/branch/master/systemui.xml | 17:31 |
| dsc_ | do I understand correctly we need a mechanism to auto-suspend when the screen has been blanked for X amount of time? | 17:31 |
| freemangordon | I meant that you can easily add button in powerkey menu | 17:32 |
| freemangordon | I am not sure we shoud auto-suspend | 17:32 |
| freemangordon | *should | 17:32 |
| dsc_ | ok | 17:32 |
| freemangordon | maybe someone can run AI on that repo and ask it to generate documentation | 17:32 |
| dsc_ | freemangordon: btw, now that you are here | 17:33 |
| dsc_ | Qt apps with QtQuick scenes seem to render at 25 fps for me, and with QT_QUICK_BACKEND=software, it renders at 125fps | 17:34 |
| dsc_ | this GPU rendering also seems to introduce some stuttering at times | 17:34 |
| dsc_ | do you think this is Lima or our Qt maemo integration? | 17:34 |
| freemangordon | most-probably it is HW sync | 17:35 |
| dsc_ | (this 125fps I dont understand btw, because QML scenes are vsync'd, and pinephone refresh rate is not 125fps) | 17:35 |
| dsc_ | (but probably due to how I measure things) | 17:35 |
| Wizzup | freemangordon: dsc_: no, I don't think we want a human triggered s2r and I also don't think we should want that in general unless we have the right wake up in place and also the proper inhibit suspend locks | 17:35 |
| Wizzup | dsc_: there is a mesa env var for vblank override | 17:36 |
| dsc_ | yes I found it | 17:36 |
| freemangordon | dsc_: OTOH https://talk.maemo.org/showthread.php?t=55734 | 17:36 |
| dsc_ | I tried vblank_mode=0 IIRC | 17:36 |
| freemangordon | Wizzup: I didn't say we shall add such entry for everyone, it is for dsc_ to experiment if wants | 17:37 |
| dsc_ | yes, thanks :) | 17:37 |
| freemangordon | BTW it is chatgpt that pointed me to that link :D | 17:37 |
| dsc_ | freemangordon: what do you mean with HW sync btw | 17:38 |
| freemangordon | vsync | 17:38 |
| freemangordon | do we know what is panel refresh rate? or it is cmdmode panel? | 17:38 |
| dsc_ | 60hz it seems | 17:39 |
| freemangordon | dsc_: could you run glmark2 to see what it will show? | 17:39 |
| freemangordon | glmark-es2 that is | 17:39 |
| freemangordon | maybe you should have to build it from the repo | 17:39 |
| dsc_ | well, my issue with glmark2/glxgears is that it starts in landscape mode, which is laggy by default (on pinephone) | 17:39 |
| dsc_ | (even with orientation lock) | 17:39 |
| freemangordon | no way | 17:40 |
| freemangordon | why would it rotate? | 17:40 |
| freemangordon | also, I guess you can force-rotate h-d | 17:40 |
| dsc_ | I think it rotates because the application window has not communicated it supports potrait | 17:40 |
| dsc_ | (but thats just guessing) | 17:41 |
| freemangordon | I see | 17:41 |
| freemangordon | you can force-rotate through h-d.ini | 17:41 |
| freemangordon | dsc_: https://git.maemo.org/leste/hildon-desktop/src/branch/master/data/transitions.ini#L230 | 17:41 |
| dsc_ | ah | 17:42 |
| freemangordon | if you start it via osso-xterm, that may explain it | 17:42 |
| freemangordon | I wonder why is osso-xterm blacklisted | 17:43 |
| dsc_ | suppose I need to restart hildon | 17:43 |
| dsc_ | how to? | 17:43 |
| freemangordon | hehe https://git.maemo.org/leste/hildon-desktop/commit/2cc7f9ae4bc07f1e9608992ec3a019c043d3564f | 17:43 |
| dsc_ | ah just killall | 17:43 |
| freemangordon | killall hildon-desktop | 17:43 |
| freemangordon | omg 14 years ago | 17:43 |
| dsc_ | it still goes into landscape | 17:44 |
| freemangordon | how do you start it? | 17:44 |
| dsc_ | via ssh, and also osso-xterm | 17:45 |
| freemangordon | hmm | 17:45 |
| dsc_ | or ehm, "X terminal" | 17:45 |
| dsc_ | yes | 17:45 |
| freemangordon | does ctrl-shift-r work? | 17:45 |
| freemangordon | oh, no keyboard :) | 17:45 |
| freemangordon | sec | 17:45 |
| dsc_ | xdotool search --name "glxgears" windowactivate --sync key ctrl+shift+r | 17:46 |
| dsc_ | we shall try | 17:46 |
| dsc_ | nope | 17:47 |
| dsc_ | ctrl-c worked, it closed it :P | 17:47 |
| dsc_ | oh wait | 17:47 |
| freemangordon | no, you should send that to h-d | 17:47 |
| dsc_ | it magically rotated after ctrl-c | 17:47 |
| freemangordon | or h-h | 17:48 |
| freemangordon | yeah, to h-d | 17:48 |
| freemangordon | try: | 17:48 |
| freemangordon | dbus-send --system --type=signal /com/nokia/mce/signal com.nokia.mce.signal.sig_device_orientation_ind string:'portrait' | 17:48 |
| dsc_ | xdotool search --name "glxgears" windowactivate --sync key ctrl+shift+r | 17:48 |
| dsc_ | ^-- this works, just need to "alt-tab" it | 17:48 |
| freemangordon | ok | 17:48 |
| dsc_ | ok so, 45fps in portrait | 17:49 |
| dsc_ | 17fps in landscape | 17:49 |
| dsc_ | the landscape is expected (on pinephone) | 17:49 |
| freemangordon | mhm | 17:49 |
| dsc_ | but I think 45fps is too slow | 17:49 |
| freemangordon | it is | 17:49 |
| freemangordon | d4 does ~ 80 on glmark2-es2 | 17:49 |
| dsc_ | do you want me to look with renderdoc | 17:50 |
| freemangordon | you run glmark2-es2, right? | 17:50 |
| dsc_ | no glxgears | 17:50 |
| dsc_ | ill try glmark2 | 17:50 |
| freemangordon | no, forget about glxgears | 17:50 |
| freemangordon | yes, do glmark-es2 | 17:50 |
| freemangordon | keep in mind mail400 is not the best gpu around :) | 17:50 |
| freemangordon | hmm, I shall run glmark on my tabletg | 17:51 |
| dsc_ | well yeah | 17:51 |
| freemangordon | not now though, have to do some cooking, bbl | 17:51 |
| dsc_ | I see a horse and a box, they render at ~45fps | 17:52 |
| dsc_ | yeah its not smooth | 17:52 |
| dsc_ | glmark2-es same story | 17:56 |
| Wizzup | freemangordon: pinephone has a higher res than most of our devices | 17:58 |
| Wizzup | imo portait performance is more than acceptable for me in the pp | 17:59 |
| dsc_ | portrait works great, very smooth | 17:59 |
| dsc_ | (hildon, that is) | 17:59 |
| freemangordon | Wizzup: sure, portrait perf is ok | 17:59 |
| freemangordon | 45fps *is* ok | 18:00 |
| freemangordon | but, this is what n900 does :) | 18:00 |
| freemangordon | or even more | 18:00 |
| Wizzup | not at 720p :p | 18:00 |
| dsc_ | its the irregular stalls that bother me, which is prevalent when scrolling through lists @ QtQuick | 18:01 |
| freemangordon | IIRC glmark score on n900 is 36 or somesuch | 18:01 |
| Wizzup | r w/e the res is | 18:01 |
| Wizzup | pp is 1440x720 | 18:01 |
| freemangordon | so? | 18:01 |
| Wizzup | the n900 fits in that almost four times | 18:01 |
| freemangordon | so? it is still the same fps | 18:01 |
| freemangordon | no matter the reasons :) | 18:01 |
| Wizzup | sure | 18:01 |
| dsc_ | i dont understand how hildon can be so smooth, but a very simple QML scene renders at 25fps | 18:02 |
| freemangordon | hildon is optimised | 18:02 |
| dsc_ | i think hildon runs at a locked 60hz | 18:03 |
| dsc_ | it feels really smooth | 18:03 |
| freemangordon | also, are you sure you don;t use qwidget? | 18:03 |
| dsc_ | I made a test QML program with a moving rectangle + fps counter | 18:03 |
| dsc_ | https://git.maemo.org/sanderfoobar/qt5-qml-fps2 | 18:03 |
| freemangordon | if you embed qml (so qgraphicsscene or something like that) in qwidget, then you kill the perf because it has to do readback | 18:04 |
| dsc_ | yes I do that | 18:04 |
| dsc_ | but I also tried the other one, QML as application window | 18:04 |
| dsc_ | https://git.maemo.org/sanderfoobar/qt5-qml-fps | 18:04 |
| dsc_ | https://git.maemo.org/sanderfoobar/qt5-qml-fps2 <== standalone QML | 18:04 |
| dsc_ | the first one is QML inside QtWidgets | 18:04 |
| dsc_ | first one = 25fps, 2nd one is ~45fps | 18:05 |
| freemangordon | I admit I don't know how qml works | 18:05 |
| dsc_ | so you're saying it readsback | 18:05 |
| dsc_ | i think thats very likely | 18:05 |
| freemangordon | so, the first one does readback | 18:05 |
| freemangordon | also, maybe there is something with modesetting driver | 18:05 |
| freemangordon | maybe it does not do double-buffering | 18:06 |
| dsc_ | because QtWidgets is painted via CPU, so if we have a QML scene rendered with the GPU, it will still have a CPU readback | 18:06 |
| freemangordon | that kills the performance | 18:06 |
| freemangordon | you should do everything on GPU | 18:07 |
| freemangordon | keep in mind mali is tiled GPU | 18:07 |
| freemangordon | (also) | 18:07 |
| dsc_ | with Qt6 I can render to an OpenGL texture and do something with that | 18:07 |
| dsc_ | (i am already very familiar with that offscreen Qt6 stuff) | 18:07 |
| dsc_ | they introduced a new system called RHI | 18:08 |
| dsc_ | I am using it for https://godotwebview.com/ | 18:08 |
| freemangordon | so, glReadPixels is your enemy (as is glFlush())\ | 18:08 |
| freemangordon | we have qt6 in maemo | 18:08 |
| freemangordon | afaik | 18:08 |
| * freemangordon is back to cooking | 18:08 | |
| dsc_ | suppose renderdoc will show those calls | 18:09 |
| dsc_ | I should check | 18:09 |
| freemangordon | dsc_: rendering to texture does not hlp much if you want CPU to access it | 18:12 |
| dsc_ | why should the CPU access it? | 18:12 |
| freemangordon | it still has to wait fpor rendering to finish so your texture to be ready | 18:12 |
| dsc_ | hildon can just show a texture or no? | 18:13 |
| dsc_ | :p | 18:13 |
| dsc_ | or ehm, QtWidgets will have a QOpenGLWidget | 18:13 |
| dsc_ | (but then perhaps we'll have the same issue) | 18:14 |
| dsc_ | anyway, not important now | 18:15 |
| dsc_ | side-note: QT_QUICK_BACKEND=software also feels faster in the VM | 18:16 |
| freemangordon | feels? | 18:33 |
| freemangordon | start h-d with G_MESSAGES_DEBUG=all CLUTTER_SHOW_FPS=1 | 18:33 |
| dsc_ | freemangordon: is there a way to drop into a shell with a key combination for the VM | 18:38 |
| dsc_ | SSH not working anymore, and hildon-desktop partially came up it seems | 18:38 |
| dsc_ | nvm, Ill mount the qcow2 disk to fix the VM | 18:39 |
| dsc_ | how do you start hildon-desktop with such env. vars? | 18:39 |
| dsc_ | ah, /etc/X11/Xsession.post/20hildon-desktop | 18:45 |
| dsc_ | idk where FPS ends up, I tried searching | 18:55 |
| dsc_ | or logs in general | 18:55 |
| dsc_ | ETA systemd :P | 18:55 |
| freemangordon | dsc_: from ssh, stop h-d (with dsmetool) and then just start it from there | 18:58 |
| dsc_ | pinephone+leste works pretty well must say | 20:33 |
| dsc_ | im going to install postmarketOS and see what they are up to | 20:33 |
| sicelo | you'll need to decide on a UI :-) | 20:34 |
| sicelo | forget Plasma ... it's painful on the pinephone | 20:35 |
| sicelo | at least that's the general opinion. it does work though | 20:35 |
| sicelo | on pp the winner is sxmo, or if you want something more conventional, Phosh | 20:36 |
| dsc_ | ok, ill try sxmo :) | 20:36 |
| sicelo | haha, someone won't touch gtk with a ten-foot pole :p | 20:46 |
| dsc_ | sicelo: hey, im using Ubuntu on my desktop :) | 20:47 |
| sicelo | my problem with sxmo is that it causes nearly 100% constant cpu load on N900. yes N900 is super weak, but it runs Leste without issues. So I guess/assume that whatever is killing the N900 will be killing beefier devices too (just it won't be obvious) | 20:51 |
| dsc_ | sicelo: but seriously, I kind of skipped this whole Pinephone stuff past 5 years, people are complaining about things etc. but when I try Leste right now, I mean it works pretty good \o/ | 20:52 |
| dsc_ | maybe I am easily impressed, this is why I want to try other distros | 20:53 |
| dsc_ | to see whats the status there | 20:54 |
| sicelo | PP is great device, I think :-) | 20:54 |
| dsc_ | yes | 20:54 |
| sicelo | i guess people are just more used to Android/iOS | 20:54 |
| Wizzup | dsc_: don't forget that leste works smooth on the PP where most Oses do not | 20:55 |
| Wizzup | sxmo might, but phosh and plasme are pretty slow on it | 20:55 |
| sicelo | btw gtk is dropping gles2 support, worsening the PP's woes | 21:07 |
| dsc_ | yes I read about it | 21:09 |
| Wizzup | sicelo: gtk4 or what? | 21:37 |
| Wizzup | sicelo: dpesm | 21:37 |
| Wizzup | sicelo: doesn't lima support opengl? | 21:37 |
| Wizzup | but yeah gnome folks will do gnome things, they also plan to drop X no :) | 21:37 |
| dsc_ | no its the hardware, mali 400 | 21:37 |
| Wizzup | dsc_: are you sure? | 21:37 |
| dsc_ | this GPU cannot support opengl3 because its missing some features | 21:37 |
| dsc_ | yes | 21:37 |
| Wizzup | I didn't see anyone say opengl3 | 21:38 |
| Wizzup | I just saw opengl :) | 21:38 |
| dsc_ | https://docs.mesa3d.org/drivers/lima.html#faq | 21:38 |
| dsc_ | but fear not, there is now https://github.com/kkofler/gtk :P | 21:39 |
| Wizzup | pretty sure lima exposes opengl 2.o0 | 21:39 |
| dsc_ | yes it does, but gtk4 went to opengl / es 3.0 | 21:40 |
| Wizzup | that'd dumb | 21:40 |
| Wizzup | that's dumb | 21:40 |
| dsc_ | they did it though | 21:40 |
| dsc_ | :p | 21:40 |
| dsc_ | they killed the pp! | 21:40 |
| Wizzup | being dumb hasn't stopped gnome before :D | 21:40 |
| dsc_ | (and quite a large amount of devices tbh) | 21:41 |
| Wizzup | OpenGL version string: 2.1 Mesa 22.3.6 | 21:41 |
| Wizzup | (PP) | 21:41 |
| dsc_ | yup | 21:42 |
| Wizzup | back in an hour or so | 21:42 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!