| Wizzup | with gles the fonts don't render in 2d, only in 3d | 00:03 |
|---|---|---|
| Wizzup | and in 3d the swizzle is wrong | 00:03 |
| Wizzup | and all the other problems persist :) | 00:03 |
| uvos | "with gles the fonts don't render in 2d, only in 3d" ? | 00:08 |
| Wizzup | yeah they become rectangles | 00:10 |
| uvos | i dont understand what 2d vs 3d means here | 00:10 |
| Wizzup | also qml scrolling was messed up | 00:10 |
| Wizzup | uvos: like status applet clock was not readable | 00:11 |
| Wizzup | not app launcher icons are | 00:11 |
| Wizzup | s/not/but/ | 00:11 |
| uvos | this isent because the dpi is correct? | 00:11 |
| uvos | (gtk2 is horribly broken with correct dpi) | 00:11 |
| Wizzup | it onl happens with gles | 00:11 |
| uvos | ok | 00:11 |
| Wizzup | and red and blue are swapped in gl/gles apps | 00:13 |
| Wizzup | also hildon home icons | 00:13 |
| uvos | heh | 00:14 |
| Wizzup | yeah. idk how this can be so broken really | 00:14 |
| Wizzup | lol | 00:14 |
| uvos | that sucks tho | 00:17 |
| uvos | this means that that making xorg work on on pp is quite some work | 00:18 |
| Wizzup | yeah | 00:18 |
| uvos | maybe sxmo | 00:18 |
| uvos | knows how | 00:18 |
| Wizzup | do they use 3d? | 00:18 |
| uvos | no idea | 00:18 |
| uvos | but surely they must no? | 00:18 |
| uvos | or do you think they uses totaly unacellerated x | 00:18 |
| Wizzup | don't know | 00:20 |
| Wizzup | we can try to cherry pick other glamor patches | 00:20 |
| Wizzup | unmerged ones | 00:20 |
| uvos | Free space 2048 255 18446744073709549824 16E | 00:21 |
| uvos | heh | 00:21 |
| uvos | cfdisk gets realy confused on mz617 | 00:21 |
| uvos | 16 Exabites free | 00:22 |
| uvos | i dont think so | 00:22 |
| uvos | *byte | 00:22 |
| Wizzup | heh | 00:25 |
| Wizzup | working on the display? | 00:25 |
| uvos | yeah | 00:25 |
| Wizzup | :) | 00:26 |
| Wizzup | https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/401 this probably fixes swizzle | 01:23 |
| Wizzup | heh: https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Server-21.1.2 | 02:12 |
| Wizzup | uvos: I think probably 5.14 needs the leste-config for pine64, but 5.10 still uses the old one | 02:17 |
| sicelo | sxmo definitely uses 3d, although they're now in the process of completely switching to wayland | 09:17 |
| sicelo | iirc they currently use x and wayland in parallel (sxmo, swmo) | 09:18 |
| tmlind | Wizzup: sounds like fremantel bandgap is only periodically enabled, looks like oma34xx is missing the thermal shutdown features | 09:34 |
| tmlind | Pali: so is your bme taking care of charger thermal shutdown? | 09:35 |
| freemangordon | IIRC, on fremantle nokia kernel bandgap was not enabled/used at all | 09:42 |
| freemangordon | in kernel-power we enabled it, but I am not sure we used it at all | 09:43 |
| freemangordon | battery thermistor is used for temperature measurement, if I am not mistaken | 09:44 |
| freemangordon | 'battery' means it is close to battery, not built-in to | 09:44 |
| freemangordon | joerg: do you remember how it all was? ^^^ | 09:45 |
| tmlind | freemangordon: i'm mostly worried about what shuts down the system if battery overheats during charging, i guess there's no hardware based thermal shutdown on bq27200? | 09:57 |
| tmlind | hmm maybe the charger needs to be kicked periodically to keep charging enabled? | 09:58 |
| tmlind | heading out here, on a spotty connection on my d4 | 09:59 |
| freemangordon | userspace shuts it down | 10:13 |
| freemangordon | there is a dsme plugin which reads temperature from bme (iirc), lemme check | 10:13 |
| freemangordon | https://github.com/community-ssu/dsme/blob/master/modules/thermalsensor_omap.c | 10:14 |
| freemangordon | https://github.com/community-ssu/dsme/blob/master/modules/thermalsensor_omap.c#L84 | 10:15 |
| freemangordon | hmm, can;t find dsme bme plugin code :( | 10:18 |
| freemangordon | ah, here it is: | 10:19 |
| freemangordon | https://github.com/community-ssu/dsme-thermalobject-surface/blob/master/modules/thermalsensor_battery.c | 10:19 |
| freemangordon | tmlind: so, dsme plugin reads MADC temperature sensor values and reports temperature to dsme, which takes overheat shutdown decision. OMAP sensor seems to be explicitly disabled | 10:22 |
| freemangordon | pali: please confirm ^^^ | 10:22 |
| freemangordon | hmm, I shal pull that to leste, at least for n900 | 10:25 |
| freemangordon | though I guess it makes sense for all devices | 10:25 |
| Wizzup | freemangordon: point is that atm bandgap is unstable | 10:46 |
| Wizzup | having it loaded with cpu_thermal causes oopses | 10:46 |
| freemangordon | Wizzup: yes, I know, but that seems to be a kernel driver issue | 10:54 |
| freemangordon | nokia disabled it because the reading is useless | 10:54 |
| freemangordon | AFAIK | 10:54 |
| freemangordon | not to say I still hold on to "on mobile it is userspace that shall take shutdown decisions" | 10:55 |
| Wizzup | I suppose from kernel perspective there might not be mobile userspace | 10:56 |
| uvos | i think reling on userspace of thermal shutdown is bad design | 10:56 |
| uvos | *for | 10:56 |
| freemangordon | sure, but userspace should at least have a knob to tell kernel "don;t kare about thermal shutdown stuff" | 10:57 |
| freemangordon | *care | 10:57 |
| freemangordon | uvos: not really, kernel doesn;t have all the information | 10:57 |
| freemangordon | BTW, the same goes for low battery | 10:57 |
| freemangordon | kernel has no idea of "emergency call" | 10:58 |
| uvos | you can maybe have it turn it off in parts yeah | 10:58 |
| uvos | but the kernel must support it | 10:58 |
| uvos | userspace is not allways runing | 10:58 |
| freemangordon | sure | 10:58 |
| uvos | or reactive | 10:58 |
| freemangordon | no doub;t about that | 10:58 |
| freemangordon | I am saying that userspace should be able to take over that | 10:58 |
| Wizzup | sicelo: well the question was do they use glamor | 10:59 |
| freemangordon | Wizzup: sorry for not helping you with xorg, I change that today :) | 11:00 |
| Wizzup | freemangordon: no worries, I built it already | 11:00 |
| freemangordon | I had 2 almost sleepest nights having to take care of some production issues in one of the systems we support | 11:00 |
| Wizzup | it doesn't change that much for pinephone unfortunately though it seems | 11:00 |
| Wizzup | yikes | 11:00 |
| Wizzup | java? :p | 11:00 |
| freemangordon | no | 11:00 |
| freemangordon | TAL :p | 11:00 |
| uvos | someone mentioned that accel dosent work on pp on dri2 | 11:01 |
| freemangordon | ever heard about? | 11:01 |
| uvos | so glamor is the only choice | 11:01 |
| uvos | if thats true | 11:01 |
| freemangordon | Wizzup: it was not related to log4shell | 11:01 |
| freemangordon | it was a planned migration which almost turned out to be a disaster because the SW provider left a bug in one of the file conversion routines | 11:02 |
| Wizzup | freemangordon: yikes | 11:02 |
| freemangordon | yeah :) | 11:02 |
| Wizzup | uvos: what accel would that be? | 11:03 |
| freemangordon | dri3 | 11:03 |
| freemangordon | I guess | 11:03 |
| Wizzup | uvos: also it's surprisingly smooth in portrait, but not in landscape | 11:03 |
| uvos | any kind of 3d | 11:03 |
| Wizzup | but there are real weird bugs, like just having conversations open causes it to glitch on the edges near the screen | 11:03 |
| uvos | (ie client or x's own rendering) | 11:03 |
| Wizzup | it keeps wiggling around | 11:03 |
| freemangordon | Wizzup: because it is rotated in SW | 11:04 |
| Wizzup | like some animation that never stops | 11:04 |
| uvos | its rotated in gl | 11:04 |
| uvos | not sw | 11:04 |
| freemangordon | not really | 11:04 |
| uvos | yes really | 11:04 |
| freemangordon | how do you know? | 11:04 |
| uvos | it uses the glamor pixmap rotating function | 11:04 |
| uvos | for the framebuffer | 11:04 |
| freemangordon | it doesn;t makes sense to me then | 11:04 |
| uvos | i traced this some time ago | 11:04 |
| Wizzup | you have a pp? I forgot | 11:05 |
| uvos | no | 11:05 |
| uvos | i traced how glamor rotates | 11:05 |
| freemangordon | PP has powerful GPU, it should not make it stutter on GL rotation | 11:05 |
| Wizzup | well in landscape it is so slow I thought it was llvmpipe | 11:05 |
| uvos | on desktop | 11:05 |
| freemangordon | uvos: it is not glamor, but modesetting | 11:05 |
| uvos | yes/no | 11:05 |
| uvos | or really no | 11:05 |
| freemangordon | Wizzup: maybe try to disable shadow framebuffer | 11:06 |
| Wizzup | ok | 11:06 |
| freemangordon | and see if it gets better | 11:06 |
| Wizzup | freemangordon: this 1 bit font problem you found btw | 11:06 |
| Wizzup | does that cause fonts to get rendered poorly? | 11:06 |
| uvos | so theres a file part of the randr extenstion that sets the transformation matrix property on the pixmap of the root window | 11:06 |
| freemangordon | Wizzup: will provide pacthes later on | 11:06 |
| Wizzup | ok | 11:06 |
| uvos | the other window's pixmaps are subwindows of the root window ofc | 11:06 |
| uvos | so they all get it | 11:06 |
| uvos | this makes glamor apply all the matrixies in the normal pximap rendering pipleine | 11:07 |
| uvos | causeing everything to be rotated | 11:07 |
| uvos | this dosent touch the ddx at all | 11:07 |
| freemangordon | ok, but that doesn;t explain the slowness | 11:07 |
| uvos | it stays at native oritation | 11:07 |
| uvos | sure i have no idea why its so slow on pp | 11:07 |
| freemangordon | GL doesn;t really care if it is rotated on 0 or 270 degrees | 11:07 |
| freemangordon | so it must be modesetting doing SW pixmap copy to the shadow FB | 11:08 |
| freemangordon | the same I was seeing on d4/n900 | 11:08 |
| uvos | thats not true tho | 11:08 |
| uvos | iirc glamor uses a diferent path for pixmaps that dont have a transformation matrix set and ones that do iirc | 11:09 |
| freemangordon | uvos: wait, you were saying it is kernel that shall rotate, no you say glamor | 11:09 |
| freemangordon | *now | 11:09 |
| uvos | ? | 11:09 |
| uvos | no xorg has internal transformation matrixes | 11:09 |
| uvos | not the planes | 11:09 |
| freemangordon | I remember we were discussing that modesetting shall set atomic property for the kernel to roatate | 11:10 |
| freemangordon | ah, ok | 11:10 |
| uvos | this is something else | 11:10 |
| uvos | these are used by glamor to rotated windows | 11:10 |
| freemangordon | but who takes the decision what to use? | 11:10 |
| uvos | (even indipendant of full screen rotation) | 11:10 |
| uvos | randr | 11:10 |
| freemangordon | then maybe we have a bug in randr | 11:10 |
| uvos | or really not | 11:11 |
| uvos | it just sets the matrix | 11:11 |
| freemangordon | because I can confirm on d4 rotation was done in SW | 11:11 |
| uvos | in non accelerated x the matrix just dose nothing | 11:11 |
| uvos | and modesetting rotates in ddx | 11:11 |
| uvos | so the framebuffer is really roated | 11:11 |
| freemangordon | for modesetting/glamor | 11:11 |
| uvos | the decision is implicit | 11:11 |
| uvos | the matrixies are allways there | 11:11 |
| uvos | but only glamor uses it | 11:12 |
| uvos | (maybe xaa/exa dose too idk) | 11:12 |
| uvos | so if glamor is not in use the windows get renderd at 0 deg | 11:12 |
| freemangordon | again, why then landscape is so slow on pp/d4? | 11:12 |
| uvos | and the ddx has to do something else | 11:12 |
| uvos | no idea | 11:12 |
| Wizzup | so shadowfb didn't seem to matter (much) | 11:12 |
| uvos | someone ahs to trace it | 11:12 |
| freemangordon | I did on d4 and SW rotate path was taken in modesetting | 11:13 |
| Wizzup | this still bothers me: [ 26.151] (II) modeset(0): Disabling kernel dirty updates, not required. | 11:13 |
| Wizzup | also seeing this: | 11:13 |
| Wizzup | [ 26.634] (EE) glamor0: GL error: GL_INVALID_ENUM in glTexParameter(pname=GL_TEXTURE_SWIZZLE_A) | 11:13 |
| Wizzup | [ 26.634] (EE) | 11:14 |
| Wizzup | [ 26.634] (EE) Backtrace: | 11:14 |
| Wizzup | [ 26.636] (EE) 0: /usr/lib/aarch64-linux-gnu/dri/sun4i-drm_dri.so (__driDriverGetExtensions_d3d12+0x129a08) [0x7f9df20920] | 11:14 |
| Wizzup | (but the GL path worked better then GLES on lima) | 11:14 |
| uvos | so its xf86RotateCrtcRedisplay | 11:19 |
| joerg | freemangordon: yes, in N900 you meant? the "temperature" usually seen is that of the charger chip, not of battery. CPU temperature was considered SiErr broken and not used | 11:20 |
| uvos | and below | 11:20 |
| joerg | the thermistor is supposed to actually measure battery temp but iirc was not exposed in kernel filesystems | 11:21 |
| joerg | you could read it out via ADC iirc | 11:21 |
| joerg | which BME actually did | 11:22 |
| uvos | not reading the cpu temperature at all is kinda flippant :P | 11:22 |
| Wizzup | freemangordon: from my perspective btw I think having pine64 gpu/X behave more would be nice but I don't consider it too urgent, I just wanted to try it out to see if newer glamor and mesa helped, and it probably is less crashy, it didn't solve all the problems | 11:22 |
| Wizzup | so this is not urgent from my perspective, n900 X I think would be more important | 11:22 |
| freemangordon | ok | 11:25 |
| freemangordon | joerg: yeah, and we later on exposed MADC readings through rx51_battery | 11:26 |
| freemangordon | thanks | 11:26 |
| Wizzup | we explicitly disable rx51_battery atm since it's otherwise quite useless | 11:26 |
| freemangordon | wait, why? | 11:26 |
| Wizzup | (and it tells upower we have two batteries) | 11:26 |
| freemangordon | so? | 11:26 |
| freemangordon | a colleague of mine as laptop with 2 batteries | 11:27 |
| freemangordon | *has | 11:27 |
| Wizzup | the n900 doesn't have two batteries | 11:27 |
| joerg | freemangordon: yw | 11:27 |
| Wizzup | maybe it's only for 5.1 btw | 11:27 |
| freemangordon | ok, but rx51_battery provides temp sensor | 11:28 |
| freemangordon | I don't remember what else though | 11:28 |
| Wizzup | we don't have it in 5.15 I think | 11:28 |
| freemangordon | we should | 11:28 |
| freemangordon | otherwise we don;t have sensor | 11:28 |
| Wizzup | I mean we don't have the patch that reverts it | 11:28 |
| freemangordon | ah :) | 11:28 |
| Wizzup | imho though we probably have too many modules loaded making the idle stuff all the harder | 11:29 |
| Wizzup | e.g. the omap3isp stuff also caused trouble | 11:29 |
| Wizzup | and we don't even have anything that uses it yet | 11:29 |
| Wizzup | but that's just a general remark | 11:29 |
| freemangordon | rx51_battery should idle just fine | 11:29 |
| Wizzup | OMAP3_THERMAL for sure dosen't, I spent ~6 hours bisecting it | 11:30 |
| Wizzup | but yeah, we'll see | 11:30 |
| freemangordon | at least on n900 it is useless afaik | 11:31 |
| joerg | my take on this two-battery problem is that the device description (DTS? DTD?) and/or the driver architecture doesn't match the real hardware | 11:31 |
| freemangordon | or rather attempting to put everything in the kernel | 11:32 |
| freemangordon | but yea, we have some general issue here | 11:32 |
| freemangordon | Wizzup: maybe we shall come-up with some 'aggregate' power device kernel framework | 11:33 |
| uvos | we also have the same problem on mz617 | 11:33 |
| uvos | it also has 2 battery chips for one battery | 11:33 |
| freemangordon | or, teach upower to handle such cases | 11:33 |
| freemangordon | maybe that'd be easy | 11:35 |
| joerg | pali and me designed rx51_battery(?) module as a foundation for acomprehensive alternative to BME | 11:35 |
| freemangordon | joerg: there is nothing wrong with it | 11:35 |
| freemangordon | it is that upower is not smart enough to know bq and rx51 drivers are about the same physical battery. or we are not smart enough to tell it to :) | 11:37 |
| freemangordon | yeah, 'composite_power' device framework will do the job | 11:37 |
| freemangordon | but I am not the one to implement that :) | 11:38 |
| Wizzup | I think we are smart enough to pick the right device from upower btw | 11:40 |
| Wizzup | it just means that every tool has to be smart enough | 11:41 |
| Wizzup | in any case it's not super important atm | 11:41 |
| freemangordon | yeah | 11:41 |
| freemangordon | Wizzup: later on I will get back to you with glamor patches | 11:41 |
| freemangordon | have to leave now, ttyl | 11:41 |
| Wizzup | ok ttyl | 11:41 |
| joerg | >>upower is not smart enough to know bq and rx51 drivers...<< that's pretty much to the point. I think either via device-tree or by driver design, the bq.ko has to become a sub-feature of the *_battery.ko system | 11:53 |
| joerg | I don't know upower but sounds to me like userland, which is not supposed to have prior knowledge about particular hardware properties | 11:54 |
| joerg | 'composite_power' device framework sounds great | 11:55 |
| freemangordon | Wizzup: check your mail | 19:41 |
| Wizzup | ty | 19:44 |
| Wizzup | looks like these should fix the es2 problems I was seeing | 19:44 |
| Wizzup | I'll try them, but I think other problems will persist | 19:45 |
| freemangordon | hopefully | 19:45 |
| freemangordon | yeah | 19:45 |
| Wizzup | it's quite some weirdness in general | 19:45 |
| Wizzup | like many of the animations suddenly return later, I've randomly seen the titlebar texture rotate a bit (like we do with phone rotation) | 19:45 |
| Wizzup | (this is not gles or gl specific) | 19:46 |
| freemangordon | this is with latest mesa? | 19:46 |
| Wizzup | yes | 19:46 |
| freemangordon | we shall open a bug then | 19:46 |
| Wizzup | OpenGL ES profile version string: OpenGL ES 2.0 Mesa 21.2.5 | 19:46 |
| Wizzup | OpenGL version string: 2.1 Mesa 21.2.5 | 19:47 |
| Wizzup | I bet it's glamor and note modesetting, though | 19:47 |
| Wizzup | or rather, not lima | 19:47 |
| freemangordon | yeah | 19:47 |
| freemangordon | but try with those patches first | 19:47 |
| Wizzup | ok | 19:49 |
| Wizzup | rebuilding with gles forced | 19:50 |
| Wizzup | will let you know in ~30 mins | 19:51 |
| freemangordon | ok | 19:51 |
| Wizzup | btw, the landscape stuff got a -bit- faster with the double shadow thing I feel like | 19:51 |
| Wizzup | maybe it transfers less or something | 19:51 |
| Wizzup | that 30 mins estimate was pretty accurate :D | 20:22 |
| freemangordon | :) | 20:22 |
| Wizzup | hm I think the font rendering is still broken for me | 20:24 |
| Wizzup | but the colours look ok | 20:24 |
| Wizzup | other corruption is also still there | 20:27 |
| freemangordon | :( | 20:27 |
| Wizzup | not surprising since it's clearly some damage or buffer mgmt problem | 20:27 |
| Wizzup | like I can see the previous screen icons in various apps | 20:27 |
| Wizzup | like the conversations contacts overview icons, they show through on the side of the view of a single conversation when I screen | 20:28 |
| Wizzup | s/screen/scroll/ | 20:28 |
| Wizzup | freemangordon: for fonts I guess https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/119 is needed | 21:23 |
| freemangordon | no idea | 21:37 |
| freemangordon | but on d4 fonts were fine, IIRC | 21:38 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!