| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2a02-8434-b6a3-e901-daca-beef-9a0a-5e34.rev.sfr.net) | 00:18 | |
| - potash (QUIT: Quit: The Lounge - https://thelounge.chat) (~potash@user/foghorn) | 00:22 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@ip-80-113-60-100.ip.prioritytelecom.net) | 00:27 | |
| ch40 | hmm | 00:33 |
|---|---|---|
| * ch40 -> ch | 00:33 | |
| ch | maybe best to check what the desktops support (: | 00:33 |
| ch | but not today | 00:33 |
| + casparvitch (~casparvit@130.102.176.164) | 01:27 | |
| - schalken (QUIT: Quit: Leaving) (~schalken@117-118-178-69.gci.net) | 01:43 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 01:44 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 02:01 | |
| - chomwitt (QUIT: Ping timeout: 245 seconds) (~chomwitt@2a02:85f:9ad5:a100:1ac0:4dff:fedb:a3f1) | 03:23 | |
| - casparvitch (QUIT: Ping timeout: 245 seconds) (~casparvit@130.102.176.164) | 04:07 | |
| + jn_ (~quassel@2a0a-a54a-c4e6-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) | 04:19 | |
| - jn_ (QUIT: Changing host) (~quassel@2a0a-a54a-c4e6-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de) | 04:19 | |
| + jn_ (~quassel@user/jn/x-3390946) | 04:19 | |
| - jn (QUIT: Ping timeout: 276 seconds) (~quassel@user/jn/x-3390946) | 04:19 | |
| + casparvitch (~casparvit@130.102.176.164) | 04:58 | |
| - casparvitch (QUIT: Ping timeout: 240 seconds) (~casparvit@130.102.176.164) | 05:41 | |
| + casparvitch (~casparvit@1.146.79.201) | 05:42 | |
| - casparvitch (QUIT: Read error: Connection reset by peer) (~casparvit@1.146.79.201) | 07:29 | |
| + casparvitch (~casparvit@1.146.79.201) | 07:35 | |
| - casparvitch (QUIT: Read error: Connection reset by peer) (~casparvit@1.146.79.201) | 08:10 | |
| + casparvitch (~casparvit@130.102.176.164) | 08:12 | |
| - casparvitch (QUIT: Ping timeout: 240 seconds) (~casparvit@130.102.176.164) | 09:40 | |
| + mjw (~mjw@ip-80-113-60-71.ip.prioritytelecom.net) | 10:01 | |
| + chomwitt (~chomwitt@2a02:85f:9ad5:a100:1ac0:4dff:fedb:a3f1) | 10:29 | |
| + casparvitch (~casparvit@36-255-114-132.ip4.superloop.au) | 11:20 | |
| - casparvitch (QUIT: Ping timeout: 276 seconds) (~casparvit@36-255-114-132.ip4.superloop.au) | 11:27 | |
| + gsora (~gsora@user/gsora) | 11:44 | |
| + andreas-e (~Andreas@2a02-8434-b6a3-e901-daca-beef-9a0a-5e34.rev.sfr.net) | 11:51 | |
| + casparvitch (~casparvit@36-255-114-132.ip4.superloop.au) | 11:59 | |
| - BAndiT1983 (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@46.101.193.235) | 12:01 | |
| - anuejn_ (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@46.101.193.235) | 12:01 | |
| - se6astian (QUIT: Quit: se6astian) (~quassel@46.101.193.235) | 12:01 | |
| minute | cc ch https://lore.kernel.org/all/7228f2c6-fbdd-4e19-b703-103b8535d77d@redhat.com/ and https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916 | 12:12 |
| minute | sounds like openrgb upstreaming is the way for LEDs | 12:13 |
| + gustav28 (~gustav@c-78-82-54-7.bbcust.telenor.se) | 13:02 | |
| - mjw (QUIT: Ping timeout: 248 seconds) (~mjw@ip-80-113-60-71.ip.prioritytelecom.net) | 13:12 | |
| - chomwitt (QUIT: Ping timeout: 276 seconds) (~chomwitt@2a02:85f:9ad5:a100:1ac0:4dff:fedb:a3f1) | 13:35 | |
| + chomwitt (~chomwitt@2a02:85f:9a2a:ce00:1ac0:4dff:fedb:a3f1) | 13:35 | |
| - colinsane (QUIT: Ping timeout: 276 seconds) (~colinunin@97-113-88-198.tukw.qwest.net) | 13:35 | |
| dok | i am having a lots of issue with the usb on my keyboard4 today... | 13:57 |
| dok | i tried to debug a bit with cynthion/luna usb analyzer but it is not very clear to me what the issue is | 13:57 |
| dok | also reseting the usb stack does not always works | 13:58 |
| dok | which is new, it was working as workaround few days ago | 13:58 |
| dok | i don't know if this issue comes from the keyboard or from my computer | 14:01 |
| + BAndiT1983 (~quassel@46.101.193.235) | 14:03 | |
| + se6astian (~quassel@46.101.193.235) | 14:03 | |
| + anuejn (~quassel@46.101.193.235) | 14:03 | |
| dok | but someone on the usb bus is spamming ACK "transaction" not sure what this means, maybe a straight ACK packet but this is weird | 14:05 |
| Zaba | well, the usb controller polls input devices periodically, maybe that’s what you’re seeing | 14:15 |
| dok | i also see the polling of the HID IN endpoint | 14:16 |
| dok | i reverted my local modifications back to origin/master and it did got stuck again | 14:18 |
| dok | i am starting to wonder if my issue is related to the thunderstorm yesterday night | 14:19 |
| - casparvitch (QUIT: Ping timeout: 248 seconds) (~casparvit@36-255-114-132.ip4.superloop.au) | 14:21 | |
| - bkeys (QUIT: Ping timeout: 268 seconds) (~Thunderbi@98.19.131.193) | 15:02 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:08 | |
| - bkeys (QUIT: Ping timeout: 245 seconds) (~Thunderbi@66.110.201.50) | 15:28 | |
| - svp (QUIT: Ping timeout: 245 seconds) (~svp@host-79-7-240-189.business.telecomitalia.it) | 15:44 | |
| josch | minute: alsa-ucm-conf is a Depends of reform-desktop-full now | 15:48 |
| josch | minute: also nice to see your updated git committer name :) | 15:49 |
| josch | Is the Reform Next surface a different finish compared to the classic? It looks somehow more "matte" | 15:50 |
| josch | (really awesome to see the photos, it looks so good!) | 15:50 |
| bremner | ch: do you have any pointers about DT bindings? documentation, where they live in the tree, etc... | 15:52 |
| + bkeys (~Thunderbi@66.110.201.50) | 15:54 | |
| + svp (~svp@host-79-7-240-189.business.telecomitalia.it) | 16:04 | |
| + mjw (~mjw@81.175.68.189) | 16:15 | |
| jogu | dok I've been having similar issues with my V4 keyboard but I've been testing alternative firmwares. The only lead I have right now is that RGB seems to make the problem worse so disabling it or dimming it significantly might help prevent the USB device from crashing | 16:29 |
| dok | i've seen the issue regardless of the rgb level, even at the lowest setting | 16:31 |
| jogu | I've never had it happen on the official firmware with RGB off, but all other firmwares I've tried (QMK, KMK, & ZMK) show it pretty quick and even with RGB off | 16:32 |
| jogu | I haven't dug too much into debugging on the official firmware but under ZMK (Zephyr) debug logs show a lot of CRC errors, RX overflow, bit suff error even before the device dies out | 16:36 |
| jogu | lsusb shows this when it stops responding: cannot read device status, Resource temporarily unavailable (11) | 16:36 |
| jogu | Is this also what you see? | 16:36 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:48 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:48 | |
| dok | how does Zephyr handle printing the debug information? it can break/make the USB depending on how it's done | 16:49 |
| dok | the kernel sees nothing | 16:50 |
| dok | no unusual messages | 16:50 |
| * bkeys1 -> bkeys | 16:51 | |
| jogu | Not sure of the low level details how Zephyr handles printing. I've disabled USB logging (no ttyACM device) and am using a second Rpi pico connected to the UART port to get logging | 16:52 |
| dok | from my experience on barebox (u-boot fork) uart printf can break device-driver | 16:52 |
| dok | better use an external usb debugger | 16:53 |
| dok | and wireshark usbmon isn't very helpful either | 16:53 |
| jogu | Yeah, I'm sure there are better ways to debug. I'm not a hardware person and just using what I have laying around haha | 16:54 |
| [tj] | jogu: sounds like a power issue if dimming helps | 16:55 |
| - chomwitt (QUIT: Ping timeout: 276 seconds) (~chomwitt@2a02:85f:9a2a:ce00:1ac0:4dff:fedb:a3f1) | 16:55 | |
| dok | also usb hub can "help" a lot | 16:55 |
| + chomwitt (~chomwitt@2a02:85f:9a5b:c600:1ac0:4dff:fedb:a3f1) | 16:56 | |
| dok | help to make things work, not debug them ^^ | 16:56 |
| [tj] | jogu: that might be enough, if you can connect over swd then you might get more helpful information. With swd you should be able to single step the keyboards mircocontroller, this won't help a ton if it is a power issue | 16:57 |
| jogu | [tj] I tried looking at the PCB in kicad but I don't think the SWD pins are exposed | 16:58 |
| jogu | Not confident enough in my soldering skills to try anything more brave either haha | 16:58 |
| jogu | dok by external usb debugger do you mean this cynthion device you mentioned earlier/ | 16:59 |
| dok | yes, or a logic analyzer | 16:59 |
| dok | i have more used a `lecroy teledyne advisor` when debugging USB at my previous job | 17:01 |
| dok | but now at home i have a Cynthion/LUNA | 17:02 |
| dok | i didn't used much, until now | 17:02 |
| dok | i'll soon acquire a DIY/protope logic analyzer that goes to between 32 to 64 MS/s | 17:04 |
| dok | so i'll be able to see the USB line directly, at least i'll try to | 17:05 |
| - jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu) | 17:16 | |
| dok | sadly it doesn't support 5v :/ | 17:16 |
| + jogu (~jogu@user/jogu) | 17:17 | |
| jogu | I see, maybe I'll have to try and investigate getting access to a logic analyzer | 17:18 |
| - jogu (QUIT: Remote host closed the connection) (~jogu@user/jogu) | 17:31 | |
| minute | josch: thanks! | 17:31 |
| + jogu (~jogu@user/jogu) | 17:31 | |
| minute | dok: can you try another fw branch where i'm sending the reports only when needed? | 17:32 |
| dok | yeah, i haven't tried your branch | 17:33 |
| dok | but i still had the issue with the same kind of fix | 17:33 |
| dok | (i sent the MR) | 17:33 |
| minute | dok: i'm quite interested in cynthion, can you recommend it? | 17:33 |
| dok | i am very biased because i used a lecroy teledyne, so far i do not recommend cynthion, it is cool and does work but the packetry interface isn't the best. | 17:35 |
| dok | but it is still more useful than wireshark (usbmon) and can capture much longer than a logic analyzer | 17:36 |
| dok | i should try to upgrade it's firmware, seems to have changed | 17:37 |
| dok | s/firmware/gateware/ | 17:39 |
| dok | on the other hand teledyne lecroy is expensive and their software only runs on windows, is very slow and breaks often... | 17:41 |
| dok | so maybe i do recommend cynthion :) | 17:46 |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 17:57 | |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@81.175.68.189) | 18:17 | |
| minute | dok: ok thx | 18:31 |
| + bkeys (~Thunderbi@66.110.201.50) | 18:52 | |
| + mjw (~mjw@81.175.68.189) | 18:55 | |
| - bkeys (QUIT: Ping timeout: 245 seconds) (~Thunderbi@66.110.201.50) | 19:03 | |
| - kensanata (QUIT: Quit: OK) (~alex@user/kensanata) | 19:10 | |
| + kensanata (~alex@user/kensanata) | 19:11 | |
| + bkeys (~Thunderbi@98.19.131.193) | 19:13 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@98.19.131.193) | 19:49 | |
| + bkeys (~Thunderbi@98.19.131.193) | 19:51 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@98.19.131.193) | 20:00 | |
| + bkeys (~Thunderbi@66.110.201.50) | 20:08 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 20:19 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 20:19 | |
| * bkeys1 -> bkeys | 20:22 | |
| ch | bremner: docs should be in ./Documentation/devicetree/bindings but probably you have to git grep | 20:25 |
| bremner | ch: ok | 20:25 |
| + shtrophic (~m-hrdsqi@user/shtrophic) | 20:27 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 20:29 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 20:29 | |
| * bkeys1 -> bkeys | 20:32 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 20:39 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 20:39 | |
| * bkeys1 -> bkeys | 20:42 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 20:49 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 20:50 | |
| * bkeys1 -> bkeys | 20:52 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 21:00 | |
| + bkeys (~Thunderbi@66.110.201.50) | 21:00 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 21:10 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 21:10 | |
| * bkeys1 -> bkeys | 21:12 | |
| + reform8153 (~user@90.187.186.49) | 21:20 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 21:20 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 21:21 | |
| reform8153 | hello | 21:21 |
| reform8153 | someone else already tried full-upgrade? | 21:21 |
| reform8153 | i get Error: Internal Error, AutoRemover broke stuff | 21:22 |
| reform8153 | due to unsatified dependencies | 21:22 |
| * bkeys1 -> bkeys | 21:23 | |
| josch | reform8153: can you put more context in a pastebin? | 21:25 |
| reform8153 | sure | 21:27 |
| bremner | oh, I remember seeing that often ~ 1 month ago | 21:28 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 21:30 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 21:31 | |
| frickler | actually running "apt autoremove" fixed that issue for me couple of days ago | 21:33 |
| * bkeys1 -> bkeys | 21:33 | |
| + xorAxAx (sid624141@id-624141.hampstead.irccloud.com) | 21:36 | |
| xorAxAx | hi, are non rockwell CPU modules for the reform still available somewhere? | 21:36 |
| xorAxAx | or the pocket | 21:36 |
| reform8153 | this is the apt history https://pastebin.com/WctjuTbv | 21:39 |
| josch | uh funky you even recently upgraded | 21:40 |
| reform8153 | and this is the error https://pastebin.com/HSnGvw34 | 21:41 |
| josch | reform8153: if you pastebin this (only do this if you are fine with sharing which packages you have installed) then i can likely reproduce your issue locally: dpkg-query --showformat '${binary:Package}=${Version}\n' --show | 21:41 |
| josch | oh | 21:41 |
| josch | wait | 21:41 |
| josch | the issue might be more simple :) | 21:42 |
| reform8153 | great :D | 21:42 |
| josch | frickler: did your apt also get stuck because of reform-qcacld2? | 21:42 |
| josch | reform8153: can you confirm that apt wants to autoremove these? | 21:42 |
| frickler | josch: I think so, yes | 21:43 |
| bremner | xorAxAx: by chance did you mean "non-rockchip"? | 21:43 |
| josch | reform8153: what platform are you on? | 21:45 |
| reform8153 | idk if it want's to remove that. it only tells me that it can't resolve the dependency issues | 21:46 |
| reform8153 | i am on the standard mnt pocket reform with the default chipset | 21:46 |
| reform8153 | can't rememner what is was rn :) | 21:46 |
| josch | reform8153: so when you run cat /proc/device-tree/model it says this: | 21:47 |
| josch | MNT Pocket Reform with i.MX8MP Module | 21:47 |
| reform8153 | MNT Pocket Reform with i.MX8MP Moduleu | 21:47 |
| reform8153 | yes | 21:47 |
| josch | reform8153: can you give me the output of this: | 21:48 |
| josch | dpkg -l | grep qcacld | 21:48 |
| xorAxAx | bremner: yeah, sorry :D | 21:49 |
| reform8153 | https://pastebin.com/L1BZ1MV5 | 21:49 |
| xorAxAx | bremner: you dont have the rockwell version of the cpu module yet? :P | 21:49 |
| josch | reform8153: okay this is indeed a job for the autoremover | 21:49 |
| josch | reform8153: you can safely remove reform-qcacld2-6.10.9-mnt-reform-arm64 and reform-qcacld2-6.11.10-mnt-reform-arm64 | 21:50 |
| reform8153 | nice | 21:50 |
| josch | frickler: but you have a pocket with rk3588, no? | 21:50 |
| josch | reform8153: but running "sudo apt autoremove" gave you the same error you say? | 21:50 |
| reform8153 | ok will do that and then do full-upgrade | 21:50 |
| frickler | josch: ack | 21:52 |
| reform8153 | ok seem it is running | 21:53 |
| josch | xorAxAx: maybe try writing to the forum -- there are probably a couple of people who upgraded to rk3588 and want to get rid of their old board or something? | 21:53 |
| josch | xorAxAx: I can recommend the A311D with which I am writing this :) | 21:53 |
| xorAxAx | josch: ah, which manufacturer is that? | 21:54 |
| josch | xorAxAx: it's the bananapi cm4: https://shop.mntre.com/products/mnt-reform-cm4-processor-module-adapter | 21:55 |
| xorAxAx | ah, thats still available! | 21:56 |
| xorAxAx | ah, no, out of stock | 21:57 |
| - reform8153 (QUIT: Remote host closed the connection) (~user@90.187.186.49) | 21:57 | |
| + reform15982 (~user@business-90-187-186-49.pool2.vodafone-ip.de) | 21:59 | |
| reform15982 | full-uprade seems to have worked! thx for the help josh | 21:59 |
| josch | nice, glad to hear! | 22:03 |
| josch | frickler: if you have the rk3588 reform, just get rid of qcacld2 | 22:03 |
| josch | frickler: unless of course you plan to switch back to imx8mplus in the future | 22:03 |
| frickler | josch: seems it was part of the initial system image, though? would it make sense to have a platform specific cleanup tool? also no switching back, started with rk3588 right away, going to stick with it ;) | 22:05 |
| josch | frickler: yes, it's part of the system image because that system image is supposed to work out-of-the-box everywhere | 22:06 |
| josch | frickler: the clean-up-tool is called reform-check -- i don't think it would be a good idea to have a tool run "apt remove X" for you | 22:06 |
| josch | minute: do you agree that reform-check should suggest users without imx8m+ to remove the qcalcd2 package? | 22:07 |
| frickler | also the issue was just 2 days ago, seems I misremembered. I can post the history.log somewhere if you need more data to check things | 22:07 |
| reform15982 | i was actually curious... was there a stable release already for the pocket? | 22:07 |
| josch | reform15982: there is no stable release, the MNT repo is based on unstable | 22:07 |
| reform15982 | kk | 22:08 |
| josch | reform15982: and if you are thinking of Debian Trixie: that has the problem that there is no qcalcd2 | 22:08 |
| josch | well, it technically has that but there are 2 problems | 22:09 |
| reform15982 | hehe sounds like unstable is good for now :D | 22:09 |
| josch | a) building it takes ~15 minutes every time you rebuild the dkms module (okay, should be rare on stable in comparison to unstable but still...) | 22:09 |
| josch | b) you have to install the firmware manually because the firmware package ezurio-qca-firmware has been waiting in the Debian NEW queue for over a year | 22:10 |
| kfx | is there a reason the driver is dkms-ed instead of existing as a patch? has anyone tried upstreaming the driver into mainline? | 22:12 |
| josch | kfx: yes, m.inute tried and failed | 22:14 |
| - reform15982 (QUIT: Remote host closed the connection) (~user@business-90-187-186-49.pool2.vodafone-ip.de) | 22:15 | |
| kfx | :( | 22:15 |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-54-7.bbcust.telenor.se) | 22:15 | |
| josch | the vendor module is 811k loc, that's why it takes so long to build | 22:15 |
| sigrid | what's qcalcd2? | 22:17 |
| josch | https://github.com/boundarydevices/qcacld-2.0/tree/boundary-CNSS.LEA.NRT_3.1 | 22:17 |
| josch | and on top of that we add 2.2k lines of patch because the thing failed to compile on 6.7, then on 6.8, then on 6.11, then on 6.13, then on 6.14, then on 6.15... | 22:18 |
| josch | it's lots of fun every time... | 22:18 |
| sigrid | lovely | 22:19 |
| sigrid | linux kernel is sure a fast moving target | 22:19 |
| kfx | I miss the odd/even release cadence. at least back then you got more than a week out of a kernel release | 22:20 |
| josch | well, if you have 811k loc, some of the api it uses is bound to change every once in a while :D | 22:21 |
| + RoosterZero (~RoosterZe@user/RoosterZero) | 22:25 | |
| grimmware | The cost of progress. | 22:33 |
| grimmware | I’m glad I’m so helpful. | 22:34 |
| minute | josch: yes, agreed @ qcacld2 | 22:40 |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 22:41 | |
| minute | xorAxAx: check mouser and crowd supply, they should have some stock | 22:42 |
| minute | kfx: the upstream driver is ath10k | 22:43 |
| + casparvitch (~casparvit@36.255.114.132) | 23:30 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!