+ ZylonMaster (~hjcs@ool-ad02e01f.dyn.optonline.net) | 00:11 | |
- ZylonMaster (QUIT: Client Quit) (~hjcs@ool-ad02e01f.dyn.optonline.net) | 00:12 | |
- bkeys (QUIT: Ping timeout: 246 seconds) (~Thunderbi@2607:fb90:7ebd:40cf:f56:c782:460:ca3d) | 00:16 | |
+ bkeys (~Thunderbi@h167.248.96.50.static.ip.windstream.net) | 00:25 | |
gordon1 | found that, but it's in chinese (for the record) https://blog.csdn.net/weixin_43245753/article/details/126981052 | 00:39 |
---|---|---|
gordon1 | i have a feeling that's for rockchip-linux vendor fork | 00:39 |
gordon1 | rk3588 dts changes for suspend and few drops of information about tf-a | 00:40 |
+ glu__ (~glu@user/glu) | 00:43 | |
- glu_ (QUIT: Ping timeout: 260 seconds) (~glu@user/glu) | 00:44 | |
- mjw (QUIT: Ping timeout: 245 seconds) (~mjw@gnu.wildebeest.org) | 00:47 | |
- chomwitt1 (QUIT: Ping timeout: 268 seconds) (~chomwitt@2a02:587:7a13:5400:1ac0:4dff:fedb:a3f1) | 02:18 | |
+ glu_ (~glu@user/glu) | 02:37 | |
- glu__ (QUIT: Ping timeout: 252 seconds) (~glu@user/glu) | 02:38 | |
- robin (QUIT: Ping timeout: 260 seconds) (~robin@user/terpri) | 02:39 | |
+ robin (~robin@user/terpri) | 02:39 | |
- paperManu (QUIT: Ping timeout: 248 seconds) (~paperManu@107.159.71.33) | 03:12 | |
- nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@130-96-142-46.pool.kielnet.net) | 03:25 | |
+ nsc (~nicolas@i5C74DD28.versanet.de) | 03:27 | |
- L29Ah (QUIT: Ping timeout: 265 seconds) (~L29Ah@wikipedia/L29Ah) | 04:40 | |
- cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 04:52 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 05:13 | |
- Ar|stote|is (QUIT: Ping timeout: 268 seconds) (~linx@149.210.32.254) | 05:31 | |
+ Ar|stote|is (~linx@149.210.34.219) | 05:35 | |
- Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149.210.34.219) | 05:47 | |
+ Ar|stote|is (~linx@149.210.34.219) | 05:48 | |
- GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:06 | |
josch | minute: hi, could you enable gitlab CI for https://source.mnt.re/joe-albanese/reform-tools/ thank you! | 07:07 |
+ GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 07:07 | |
+ gustav28 (~gustav@c-78-82-52-87.bbcust.telenor.se) | 10:02 | |
- Gooberpatrol66 (QUIT: Read error: Connection reset by peer) (~Gooberpat@user/gooberpatrol66) | 10:03 | |
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 10:04 | |
- jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 10:04 | |
+ jacobk_ (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 10:04 | |
+ chomwitt1 (~chomwitt@2a02:587:7a13:5400:1ac0:4dff:fedb:a3f1) | 10:13 | |
- chomwitt1 (QUIT: Ping timeout: 272 seconds) (~chomwitt@2a02:587:7a13:5400:1ac0:4dff:fedb:a3f1) | 10:20 | |
minute | josch: will do | 11:41 |
minute | here's a fix for GNOME performance issues on panfrost: COGL_DRIVER=gles2 in /etc/environment | 11:42 |
grimmware | josch: I can't edit that wiki so https://paste.debian.net/1358616/ | 11:44 |
grimmware | ftdfile does not look correct | 11:45 |
grimmware | also, interestingly if I use `bootflow` from uboot console to boot via extlinux the screen isn't rotated which I guess means it's not forwarding the default bootargs | 11:49 |
josch | grimmware: thank you but fdtfile looks correct. It should be rockchip/rk3588-mnt-pocket-reform.dtb and it is | 11:49 |
grimmware | oh okay? what's that relative to? | 11:50 |
josch | to fdtdir -- did you see the bug i sent you above? | 11:50 |
grimmware | oh sorry yeah I skimmed it when I was half asleep last night - this is why I leave things on unread | 11:50 |
josch | grimmware: for u-boot arguments to be forwarded you need to have ${bootargs} in your "append" line as in the paste of my extlinux.conf that i sent you | 11:50 |
grimmware | yeah that's the thing, they are | 11:51 |
josch | grimmware: there was a change in u-boot-menu to accomodate for having a dedicated /boot partition and i think that commit is responsible for having broken it in a way that i describe in that bug | 11:51 |
josch | as a workaround, we could ship this setting by reform-tools | 11:52 |
josch | grimmware: you could test adding this to your /usr/share/u-boot-menu/conf.d/reform.conf and then regenerating extlinux.conf by running sudo u-boot-update: U_BOOT_FDT_DIR="/dtbs/" | 11:54 |
josch | grimmware: if that fixes it for you, we can change this in reform-tools until https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1091979 gets fixed | 11:55 |
josch | it's on my todo list to fix this but not very close to the top | 11:55 |
josch | lucky for me, deianara might have found the offending commit in https://community.mnt.re/t/display-flickering-on-pocket-reform-related-to-mesa-25-0-0/3133/19 | 11:56 |
josch | building mesa with that commit reverted here: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/85 | 11:56 |
grimmware | yeah nice, I've only fixed 2 of the entries in extlinux.conf and I'm about to start looking into the bisect so that's good timing | 11:56 |
minute | josch: done @ runner assignment | 11:58 |
josch | minute: thank you! that will make future contributions easier :) | 11:59 |
grimmware | josch: yeah that's done the trick :) | 12:00 |
grimmware | I'm really pleased to understand how all this stuff works on arm a bit better, feel like I can figure more boot stuff out by myself now | 12:01 |
josch | nice, thank you :) | 12:01 |
grimmware | okay, so my thinking here is that the issue was likely caused in one of the patches with the introduction of the v2 display (I am on v1, gl0b has an rcore pocket with what we suspect is the v2). From that point of view, I think I'm going to try and bisect the patches rather than the kernel, so I'm planning on pulling upstream and checking out the same version of the kernel I've been booting for most of January | 12:18 |
grimmware | I'm then going to try applying the patches from *before* the first of the alternate panel changes as I have a working kernel version from November. If that works, I'll have proven it's the patches not the upstream. | 12:19 |
grimmware | Assuming the patches apply cleanly *fingers crossed* | 12:19 |
grimmware | Interesting, from my last working preinstalled kernel from November on display re-enable: [ 1672.185505] dw-mipi-dsi2 fde30000.dsi: [drm:dw_mipi_dsi2_encoder_atomic_enable [rockchipdrm]] final DSI-Link bandwidth: 840000 x 4 Kbps | 12:37 |
grimmware | compare with broken: [ 4.528733] dw-mipi-dsi2 fde30000.dsi: [drm:dw_mipi_dsi2_encoder_atomic_enable [rockchipdrm]] final DSI-Link bandwidth: 972000 x 4 Kbps | 12:38 |
grimmware | Is there a way for me to see these messages from within a booted system? https://source.mnt.re/reform/reform-debian-packages/-/commit/5bc6a22056bea2d7a24f24e029a2b16e64972212#636a3b2572909cc01da710e2b94c795bb3214281_100_111 | 12:42 |
- cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 12:45 | |
+ L29Ah (~L29Ah@wikipedia/L29Ah) | 12:46 | |
grimmware | ah that's interesting, further to this on a broken kernel, even with the display *on* if you do a reboot the display does not come on again. | 12:58 |
grimmware | it has to be a shutdown and power on | 12:58 |
grimmware | Which furthers my suspicion that there's a bug in jdi_panel_init (not that I am an expert in these things) | 12:59 |
+ cow321 (~deflated8@user/meow/deflated8837) | 13:06 | |
+ paperManu (~paperManu@107.159.71.33) | 13:10 | |
minute | grimmware: oh, the dsi frequency changed? | 13:14 |
minute | grimmware: i didn't fully follow the log yet, what's the issue you're currently debuggng? | 13:14 |
grimmware | on a pocket with rk3588 and a v1 display, if you `swaymsg 'output DSI-1 [dpms|power] off'`, any subsequent `on` command or a reboot does not re-enable it, you need to power down and back up again | 13:15 |
minute | (i also have a curious issue since a while: fullscreen video makes wifi stop. unfullscreening, even if the video is still quite big, immediately brings wifi back) | 13:15 |
minute | grimmware: ahh, got it! | 13:15 |
minute | grimmware: i have the same setup but with gnome, and toggling the internal display is kind of hit and miss, sometimes it doesn't come on or displays noise only | 13:16 |
grimmware | minute: how long have you had the issue for? I've got a kernel from back in November that works fine | 13:17 |
minute | grimmware: not sure because i only recently switched to gnome, since a few weeks | 13:20 |
minute | weird, even having a paused youtube video on fullscreen freezes wifi (i have a ping in an always-on-top window). pressing f immediately makes the pings resume | 13:21 |
grimmware | hahah | 13:24 |
grimmware | oh man computers | 13:24 |
grimmware | minute: oh btw do you have blender installed on any of your rk3588 and if so how? I know there's a limitation for recent versions because of available opengl or something like that... | 13:25 |
minute | grimmware: blender doesn't work yet but i have a very hacked experiment of a branch where they removed geometry shaders, and with some further hacks i can get the UI to work on panvk. but it's very slow and crashes when opening material editor. so this will still need some patience... another options is to somehow install the old blender 2.8 | 13:29 |
minute | or maybe there is an eGPU we could get to work with rk3588. intel arc maybe? i still need to experiment with that | 13:29 |
minute | (amdgpu often has pcie issues with arm) | 13:30 |
grimmware | legit, it's not my hugest concern right now I just figured I'd ask | 13:30 |
minute | ok so when i stream a video on youtube in fullscreen but i mostly obscure it with a always-on-top terminal window, that unblocks wifi | 13:30 |
minute | so it's probably EMI from the display cable | 13:30 |
grimmware | is it possible to shield the aerial cables? | 13:31 |
minute | that would be the best i think | 13:32 |
minute | i guess i could try some aluminum foil here at home to see if that has an impact | 13:32 |
minute | first test now is moving the antenna for the asiarf to the other side, near ethernet port | 13:41 |
minute | yep, problem is gone | 13:45 |
grimmware | \o/ | 13:48 |
minute | we could try a custom shielded flex cable... like i did for ls1028a. the contact pattern is quite tricky though (2 rows) | 13:57 |
grimmware | is there not like, some kind of shielded heat shrink or something? | 14:14 |
minute | grimmware: i think it only really makes sense when the shield is connected to GND but i might be wrong | 14:19 |
minute | grimmware: wow indeed there is emi shielding heatshrink... nice idea | 14:19 |
grimmware | If there is a caveman solution to a problem I will suggest it | 14:38 |
minute | appreciated | 14:45 |
- cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 14:48 | |
minute | interesting discussion about GLES in gnome https://gitlab.gnome.org/GNOME/mutter/-/issues/3101#note_2365766 | 15:07 |
- glu_ (QUIT: Remote host closed the connection) (~glu@user/glu) | 15:10 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 15:31 | |
+ mjw (~mjw@gnu.wildebeest.org) | 15:41 | |
minute | one more note: i'm giving firefox 135 a spin on rk3588 pocket with gnome and latest mesa, and had tons of gfx corruption (tiles unpainted leaking through other content). turning off layers.acceleration in about:config fixed that | 15:52 |
josch | heh, wifi stops working when playing video? :D Yesterday I had my second A311D connect to my wifi even though there was no antenna connected to the board. XD | 16:24 |
- bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@h167.248.96.50.static.ip.windstream.net) | 16:25 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 16:27 | |
josch | "My theory is that fullscreen video creates enough EMI on the display flex cable that it interferes with the antenna close to it" | 16:35 |
josch | wow... | 16:35 |
josch | reminds me a bit of the problem we had with the openmoko phone back in the day where we had to hack the kernel to disallow accessing the sd-card and outputting to the display at the same time :D | 16:36 |
minute | josch: hehe yeah the bpi wifi is quite good without antennas for some reason | 17:01 |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 17:07 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 17:08 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 17:17 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 17:18 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 17:27 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 17:27 | |
* cobra_ -> cobra | 17:31 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 17:37 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 17:37 | |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 17:48 | |
+ bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 17:48 | |
* bkeys1 -> bkeys | 17:50 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 18:03 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:03 | |
grimmware | minute: okay, just trying to brain around this and I've noticed that both imx8mp and a311d are specifically mentioned in https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches6.12/imx8mp-mnt-pocket-reform/pocket-panel/0001-v5-add-multi-display-panel-driver.patch?ref_type=heads#L632-L662 based on the `init-in-enable` attribute. rk3588 doesn't have that, so I'd assume here that its init is happening in | 18:04 |
grimmware | `prepare`. Is this intentional and could it be causing the problem that I'm seeing? The narrative I'm thinking of here is that `[dpms|power] on` hits enable but not prepare meaning the display never gets re-initialized? | 18:04 |
grimmware | I don't know if what I've said there makes any sense | 18:05 |
grimmware | Oh actually this is potentially compelling: | 18:08 |
grimmware | https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches6.12/imx8mp-mnt-pocket-reform/pocket-panel/0001-v5-add-multi-display-panel-driver.patch?ref_type=heads#L519-525 vs https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches6.12/imx8mp-mnt-pocket-reform/pocket-panel/0001-v5-add-multi-display-panel-driver.patch?ref_type=heads#L664 which the rk3588 will hit | 18:08 |
- jacobk_ (QUIT: Quit: No Ping reply in 180 seconds.) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 18:10 | |
grimmware | okay never mind, it is indeed initing in prepare when it's being re-enabled - I can see it in dmesg | 18:11 |
+ jacobk_ (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 18:12 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 18:13 | |
minute | grimmware: yeah, the sequence of when dsi video stream starts vs when init vs prepare happens seems to differ between controllers/socs, that's why i made this kludge | 18:13 |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:13 | |
minute | grimmware: other problems that can happen is something goes wrong in disable | 18:14 |
grimmware | gotcha. It looks like for the rk3588 the mipi dsi low power mode is being explicitly disabled in init but it's being enabled again in enable | 18:17 |
grimmware | apologies if I'm picking apart random things, I'm trying to wrap my head around all of this | 18:17 |
- Ar|stote|is (QUIT: Ping timeout: 252 seconds) (~linx@149.210.34.219) | 18:25 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 18:27 | |
minute | grimmware: yeah, this was weeks (?) of trial and error | 18:27 |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:27 | |
+ Ar|stote|is (~linx@149.210.32.245) | 18:29 | |
- helgoman (QUIT: Ping timeout: 244 seconds) (~helgoman@adsl-178-38-58-229.adslplus.ch) | 18:32 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 18:37 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:37 | |
+ helgoman (~helgoman@adsl-178-38-58-229.adslplus.ch) | 18:41 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 18:47 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:47 | |
grimmware | minute: the only other thing I spotted so far in here is that the backlight only gets enabled if `jdi->backlight` doesn't already exist, which strikes me as suspect - it would explain why it turns on the first time but never subsequently. https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches6.12/imx8mp-mnt-pocket-reform/pocket-panel/0001-v5-add-multi-display-panel-driver.patch?ref_type=heads#L556 | 18:51 |
- hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 18:51 | |
grimmware | I don't have time to test it right now but do you think moving it to after the `if` clause makes sense to try? | 18:52 |
+ hairu (m-uotkmd@user/hairu) | 18:52 | |
- cow321 (QUIT: Ping timeout: 252 seconds) (~deflated8@user/meow/deflated8837) | 18:54 | |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 18:58 | |
+ bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 18:58 | |
* bkeys1 -> bkeys | 19:00 | |
minute | grimmware: that could be a bug, you can try moving that | 19:01 |
- hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 19:04 | |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 19:05 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 19:05 | |
+ hairu (m-uotkmd@user/hairu) | 19:05 | |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 19:08 | |
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 19:08 | |
grimmware | Cool, I’ll give that a pop tomorrow. | 19:09 |
grimmware | It’s consistent with the screen still showing up in wdisplays and there being no real errors. | 19:10 |
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 19:13 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 19:26 | |
ch | grimmware: my display has the same or at least a similar problem. at c3 i tried a lot of things in the display driver, but did not find much that was really helpful | 20:21 |
grimmware | ch: I can punt you some kernel image debs tomorrow that you can try out and see if they fix your issue - I tried some old ones I still had in /boot yesterday and they worked just fine. | 20:23 |
grimmware | Not now though, I am at the pub :) | 20:23 |
- mlarkin (QUIT: Read error: Connection reset by peer) (~mlarkin@47.158.172.62) | 20:29 | |
+ mlarkin (~mlarkin@47.158.172.62) | 20:34 | |
- jacobk_ (QUIT: Ping timeout: 260 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 20:41 | |
+ jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 20:41 | |
+ burley_ (~burley@216.49.132.151) | 20:59 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 20:59 | |
- cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 21:31 | |
- burley_ (QUIT: Quit: Leaving) (~burley@216.49.132.151) | 21:33 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 21:52 | |
+ burley_ (~burley@216.49.132.151) | 22:07 | |
- burley_ (QUIT: Client Quit) (~burley@216.49.132.151) | 22:09 | |
- gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-52-87.bbcust.telenor.se) | 22:15 | |
+ chomwitt1 (~chomwitt@2a02:587:7a13:5400:1ac0:4dff:fedb:a3f1) | 22:27 | |
- cow321 (QUIT: Read error: Connection reset by peer) (~deflated8@user/meow/deflated8837) | 22:41 | |
+ reform23424 (~toor@static-198-44-136-49.cust.tzulo.com) | 23:31 | |
- reform23424 (QUIT: Remote host closed the connection) (~toor@static-198-44-136-49.cust.tzulo.com) | 23:32 | |
+ cow321 (~deflated8@user/meow/deflated8837) | 23:44 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!