| tmlind | freemangordon: i don't have any current chromeos device, maybe the file is available for download somewhere though | 06:36 |
|---|---|---|
| tmlind | freemangordon: for tearing effect, looks like we may have some signaling misconfiguration in mainline, te triggers fine but only for some seconds to minutes with just your panel-dsi-cm changes | 06:38 |
| tmlind | then it hangs and we get the timeout errors and that's why the te got disabled earlier for the panel | 06:39 |
| tmlind | well te probably did not work at all earlier as it was missing some configuration looking at your patch | 06:41 |
| tmlind | after adding some trace_printk, looks like on framedone interrupt with te enabled the VC_TE counter is almost always 0 or very close to 0, so it seems like with te enabled, and the pending patch generating vsync on framedone, we should avoid tearing | 06:44 |
| tmlind | freemangordon: to me looks like the dsi related changes in your patch are not needed as omapdrm already configured te to set the VC_TE counter | 06:46 |
| tmlind | i guess i need to dump out the android dsi1 regs and diff the values to try to figure out if there's some signaling configuration issue | 06:46 |
| tmlind | hmm looks even with current setup without te enabled, on framedone VC_TE is mostly empty, not sure what the signal in the te case for transfer complete is really supposed to be if there's no gpio line | 07:21 |
| tmlind | it seems that TE_TRIGGER_IRQ signals that the lcd module has started transferring after bus tunaround.. so maybe there's some bta interrupt after transfer complete after another bus turnaround? | 07:23 |
| tmlind | oh there's also ACK_TRIGGER_IRQ with te enabled after framedone, that's probably what signals transfer completed from the panel | 07:35 |
| rafael2k | hi there, I'm rebasing the pp patches to latest 5.10.13, hope to finish in the weekend | 11:46 |
| Wizzup | rafael2k: hmm, we don't want 5.15? | 11:51 |
| rafael2k | sorry | 11:57 |
| rafael2k | 5.15.13 | 11:57 |
| Wizzup | :) | 12:01 |
| Wizzup | did you figure out what we want built in? | 12:01 |
| _inky | rafael2k: yay | 12:16 |
| rafael2k | hi there! | 12:27 |
| rafael2k | Wizzup: no time yet | 12:28 |
| rafael2k | my keyboard was shipped | 12:28 |
| rafael2k | so my time is running over | 12:28 |
| rafael2k | :P | 12:28 |
| Wizzup | ok | 14:59 |
| Wizzup | uvos: I'll do the volume applet today :) | 14:59 |
| jessicant | is it possible to get the pinephone keyboard working with this yet? | 16:57 |
| Wizzup | jessicant: I think it should | 17:47 |
| Wizzup | jessicant: we haven't been able to test it yet | 17:47 |
| Wizzup | jessicant: does it slide somehow, or is it just always attached? | 17:47 |
| jessicant | well it doesn't work out of the box | 17:47 |
| jessicant | it's always attached | 17:47 |
| Wizzup | jessicant: ah, you have one? | 17:47 |
| jessicant | yeah | 17:48 |
| Wizzup | jessicant: great, we have a new kernel and some other stuff to push out, it might work with that | 17:48 |
| Wizzup | I don't know what it required (a special driver?) | 17:48 |
| Wizzup | rafael2ks is active with the pine kernel now, and he also ordered the keyboard | 17:48 |
| jessicant | https://xnux.eu/pinephone-keyboard/faq.html | 17:48 |
| jessicant | there's a userspace and a kernel space driver | 17:48 |
| Wizzup | right so we don't have the kernel one then I guess | 17:50 |
| Wizzup | I'll ask rafaek to pull these in | 17:51 |
| Wizzup | freemangordon: ping | 18:03 |
| Wizzup | freemangordon: I am seeing the display not turning on problems more frequently now (it happened again today), X is still running, anything I can do to provide a way to debug this? | 18:05 |
| Wizzup | freemangordon: it must be a recent change in kernel we did, or something the ddx, because I wasn't seeing this before I think | 18:06 |
| Wizzup | maybe it is somehow the fbdev emulation? | 18:07 |
| Wizzup | I think I see this every day now on the d4 | 18:24 |
| Wizzup | it loks like X keeps retrying a thing in kernel drm that fails | 18:25 |
| uvos | Wizzup: ping | 22:13 |
| uvos | Wizzup: http://uvos.xyz/maserati/patches/0001-power-supply-cpcap-battery-Provide-battery-state-bas.patch | 22:14 |
| Wizzup | uvos: hi | 22:24 |
| Wizzup | uvos: I'll apply that to beowulf-devel kernel for d4/n900 ? | 22:24 |
| Wizzup | uvos: do you get have any problems with screens not coming on again? | 22:29 |
| Wizzup | I am not sure what is causing it, but I am wondering if perhaps somehow the fbdev patch prevented it | 22:30 |
| Wizzup | uvos: shall I add this back in for now? "drm/omap: get fbdev working for manually updated display" | 22:31 |
| uvos | Wizzup: no i have not | 22:32 |
| uvos | Wizzup: if you like, but i doubt this is the problem | 22:33 |
| uvos | Wizzup: you did update the ddx on the device where this is hanging right? | 22:33 |
| uvos | Wizzup: since there was sutch a rpoblem that fmg did fix | 22:34 |
| Wizzup | the problem is in the kernel drm ioctl | 22:36 |
| Wizzup | uvos: so when I check X it is stuck retrying the ioctl | 22:36 |
| Wizzup | and the kernel also fails and keeps retrying (because Xor requests it) the mode change | 22:36 |
| Wizzup | drm.debug=0xff shows this | 22:36 |
| uvos | ok | 22:36 |
| uvos | no never seen this | 22:36 |
| Wizzup | https://dpaste.com/2SSKGP2ZB | 22:37 |
| Wizzup | this is a part of the trace (it's also in our logs): | 22:37 |
| Wizzup | 17:40 < Wizzup> #0 0xb6a33f06 in ioctl () at ../sysdeps/unix/syscall-template.S:78 | 22:37 |
| Wizzup | 17:40 < Wizzup> #1 0xb6d24c76 in drmIoctl () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 22:37 |
| Wizzup | 17:40 < Wizzup> #2 0xb6d2923a in drmModeConnectorSetProperty () at /usr/lib/arm-linux-gnueabihf/libdrm.so.2 | 22:37 |
| Wizzup | 17:40 < Wizzup> #3 0xb66c3f12 in drmmode_output_dpms (output=<optimized out>, mode=0) at drmmode_display.c:797 | 22:37 |
| Wizzup | in any case this is a very recent problem | 22:42 |
| Wizzup | and not that much has changed in the kernel, so I thought maybe it was this | 22:42 |
| Wizzup | I think I'm going to add the fbdev thing back in for now and see if it helps | 22:43 |
| Wizzup | uvos: btw you wrote: "Note that this plus the input device locking behavior of mce (even on fremantle) makes tklock (as opposed to vtklock) totally obsolete and redundant, it no longer serves any function." | 22:50 |
| Wizzup | uvos: how about showing notification counts, doesn't tklock do that? | 22:50 |
| uvos | your thinking about _vtklock) | 22:50 |
| uvos | tklock is the contraption that locks the device ts and keypad when its locked and the screen is off (also one click mode) | 22:51 |
| uvos | vtklock is the thing with the slider | 22:51 |
| lel | MerlijnWajer closed a pull request: https://github.com/maemo-leste/maemo-statusmenu-volume/pull/1 (This pr makes this applet work on leste) | 22:51 |
| uvos | these are seperate systemui modules | 22:52 |
| uvos | tklock was allways pretty mutch redundant, except the dbus interface for the volume keys and kinda one click mode, but really that was in mce too | 22:52 |
| uvos | mce just used to avoid applying one click mode itself when tklock was active | 22:53 |
| Wizzup | ah, I see | 22:55 |
| Wizzup | thanks for the explanation | 22:56 |
| uvos | oh btw on code i removed, i dident remove any functional code | 22:57 |
| uvos | so there are 2 things i "removed" | 22:58 |
| uvos | 1 the volume slider used to check with pa about what the default stream was and set default_sink_name | 22:58 |
| uvos | and dident do anything at all with that | 22:58 |
| uvos | and 2 the slider dident set the volume immiately | 22:59 |
| uvos | instead 500ms where waited after the user last moved the slider | 22:59 |
| uvos | and then the volume was set | 22:59 |
| uvos | there is a bug in n900 hw that causes chaging the volume to result in auidble clicks | 22:59 |
| uvos | and this is was a hack around this | 23:00 |
| uvos | well noten entirley | 23:00 |
| uvos | there still is one click you can clearly hear in fremantle once it finaly sets the volume | 23:00 |
| uvos | but this hack tried to mitigate it | 23:00 |
| uvos | otherwise its just porting the interfaces | 23:00 |
| Wizzup | I thought the tick was part of the sound changing, like something that was played | 23:00 |
| uvos | nah its hw bug | 23:01 |
| Wizzup | right, but afaik there are ways for the applet to set the/track the volume on separate streams, because that did work somehow on the n900 | 23:01 |
| Wizzup | hmmm I think I also hear it on the d4 | 23:01 |
| uvos | yes this works | 23:01 |
| Wizzup | (will need to check later) | 23:01 |
| uvos | it tracks exactly 2 streams | 23:01 |
| uvos | in call and normal audio | 23:01 |
| uvos | this is unchainged | 23:01 |
| uvos | not really tracks, sets rather | 23:01 |
| uvos | honestly this is bad | 23:02 |
| uvos | (the whole applet) | 23:02 |
| Wizzup | so what I still don't understand is how it works the way it does in fremantle | 23:02 |
| Wizzup | where unplugging/plugging causes it to track the right speaker/hp sink | 23:02 |
| Wizzup | maybe it's one of the pulseaudio plugins or OHM | 23:02 |
| uvos | this is done below it | 23:02 |
| uvos | it just sets one proparty for media auido volume | 23:02 |
| uvos | its not a stream volume at all | 23:02 |
| uvos | its a stream proparty on the media streme | 23:03 |
| uvos | that something else needs to apply as volume | 23:03 |
| Wizzup | right, so that's probably ohm or pa | 23:03 |
| uvos | anyhow this is all pretty bad | 23:03 |
| Wizzup | the streams concept I am not sure is bad, but even so the media stream still differents in volume between hp/speaker | 23:03 |
| uvos | yeah but the streams apear to have been faked | 23:04 |
| Wizzup | this is also visible in how it renders the volume bar, it can be in completely different states | 23:04 |
| uvos | the volume applet makes it look liker there is only one stream | 23:04 |
| Wizzup | so it probably also fetches the current state somehow | 23:04 |
| uvos | and its role is changed | 23:04 |
| uvos | this is really a hack to how its supposed to work in pa | 23:04 |
| uvos | with different roles/profiles having own streams | 23:04 |
| uvos | we probubly just want n seperate streams | 23:05 |
| uvos | for different "roles" | 23:05 |
| Wizzup | https://web.archive.org/web/20200815080328/https://wiki.merproject.org/wiki/Nemo/Audio isn't that what is being done here? | 23:05 |
| uvos | and have the volume applet allow you to set any one of those at any time | 23:05 |
| uvos | the way the android one works, really | 23:05 |
| Wizzup | oh the orig website is back up | 23:05 |
| Wizzup | https://wiki.merproject.org/wiki/Nemo/Audio | 23:05 |
| uvos | Wizzup: no idea how meego audio works, ill read that again later. im just reporting on the volume slider | 23:06 |
| uvos | Wizzup: wich understands only one stream | 23:06 |
| uvos | besides call audio | 23:06 |
| Wizzup | check | 23:12 |
| uvos | oh and recveving events from xorg for the volume keys was also removed | 23:13 |
| uvos | since the ex-tklock dbus interface is sufficant | 23:14 |
| uvos | im not sure why they thought it nessecary to implement the input side of things twice | 23:15 |
| uvos | i think this is because the dbus interface also dident do key repeat, like mce, and they dident want key repeat moving the volume to full blast in the users pocket (android also behaves like this) | 23:15 |
| uvos | but i havent checked on fremantle if thats to | 23:15 |
| uvos | implementing the input frontend twich is an absurd way to provide this feature anyhow :P | 23:16 |
| uvos | *twice | 23:16 |
| Wizzup | makes sense, going afk for a bit :) | 23:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!