00:40 <steev> dd to the wrong device

00:41 <steev> That said… saw there was a new board-2.bin in kalle’s repo but sadly, it still doesn’t find our device in it

02:12 <davidebeatrici[m]> Always use https://github.com/jsamr/bootiso when writing to a USB drive.

02:44 <amstan> davidebeatrici: that's a little absolutist, heh

02:44 <amstan> i prefer `cros flash`

02:45 <davidebeatrici[m]> I mean, anything but `dd`. Before discovering `bootiso` I always checked at least 5 times the command before running...

02:46 <davidebeatrici[m]> Isn't `Cros Flash` ChromiumOS only? https://chromium.googlesource.com/chromiumos/docs/+/HEAD/cros_flash.md

02:46 <amstan> it probably is, heh

02:47 <amstan> yeah... idk, i wish there was a standard way to do this easily without being dangerous

02:47 <amstan> maybe udev rules to mark removable devices as user writable

02:48 <amstan> and never use sudo with dd

02:48 <amstan> i do sometimes want to partition stuff manually on that flash drive

02:48 <amstan> mount still won't work for most filesystems though

13:42 <JoshuaAshton> jenneron[m]: You'll want this to fix some rendering bugs https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18779

13:43 <jenneron[m]> JoshuaAshton: ...in windows?

13:45 <JoshuaAshton> jenneron[m]: No for Galaxy Book S

13:46 <JoshuaAshton> it wont be your display issues though

13:46 <JoshuaAshton> it fixes corrupt rendering in applications

14:20 <clover[m]> <steev> "That said… saw there was a new..." <- That was supposed to be the official wifi firmware right?

14:21 <steev> dunno

14:22 <steev> as always, changes to the board files are usually just "update board.bin" or "update board-2.bin" and absolutely no information about what changed

15:45 <clover[m]> can i see a link to the repo you are talking about?

15:47 <ajhalaney[m]> Anyone know how to get a windows iso for the x13s? I'm really struggling to figure out what you're supposed to do if you say, wipe windows, then decide you might want it for firmware updates etc :P

15:49 <qzed> clover: one of the ath ones here: https://github.com/kvalo, not sure which one applies to the x13s

15:49 <szclsya[m]> ajhalaney: you can find recovery images on lenovo support

15:58 <szclsya[m]> and the image creation tool is x86 only, comical

16:00 <ajhalaney[m]> and a windows executable I see (these support pages are not fun to navigate) -- luckily i have a x86 dual boot box laying around to make this easier... thanks Leo Shen !

16:03 <szclsya[m]> no problem :)

16:43 <clover[m]> qzed: who is kalle? someone that works for qcom?

16:44 <qzed> AFAIK yes, he maintains wifi stuff (not sure if exclusively qcom) for the kernel, including firmware

18:25 <steev> clover[m]: yes, that's his github, the ath11k is the repo i mean

18:25 <steev> he's been atheros for a long long time

18:26 <clover[m]> ok, thanks for the info!

18:27 <steev> ftr, just copying it in isn't enough, you also have to revert the wifi hack, but, again, it doesn't work

18:52 <clover[m]> i wont try it then :)

19:11 <Lucanis> robclark, apparantly its armv8 so even has 64bit support. I took the time to inspect the cpu itself.

19:18 <steev> clover[m]: https://bugzilla.kernel.org/show_bug.cgi?id=215987 is the upstream bug that (should) cover it

19:29 <robclark> Lucanis: ahh, ok, I guess the elinux wiki page is just extremely out of date

20:19 <steev> bamse: so, uh, apparently if i flip the sdcard reader over, it doesn't block the wifi

20:43 <clover[m]> <steev> "clover: https://bugzilla.kernel..." <- ok so the bug is still open for us

20:43 <steev> well, it's open for everyone, but yes

20:44 <clover[m]> im not really familiar with 'bugzilla'

20:44 <clover[m]> why doesn't kernel just use github or something similar

20:55 <robclark> because github didn't exist when the kernel bugzilla was setup, probably ;-)

21:50 <steev> i would shudder to think of having to use github for the code review for the kernel

22:00 <clover[m]> Lol!

22:06 <robclark> gitlab does have some pretty significant advantages over email list based review.. having used both myself quite a bit.. the main disadvantage is it isn't very easy to comment on the commit msg itself (but you can always copy+paste+quote into a comment unassociated with a line of code)

23:19 <clover[m]> Let's start a revolution

23:32 <robclark> getting all kernel developers to switch workflow from what they've duct taped together over the years seems unlikely to happen.. but I expect with time some individual subsystems may switch.. we are _kinda_ using gitlab for drm/msm (not for patch review, just for the pre-merge CI aspect.. but I expect once the CI setup is working as well as mesa's there would be some interest in using more of gitlab's features