00:41 <alyssa> 2633 total

00:41 <alyssa> still much too large a driver :'(

00:42 <alyssa> and too much... sketchy

01:36 <alyssa> been investigating the Xorg hotplug thing

01:37 <alyssa> correct hotplugging depends on atomic_flush() getting called on hotplug, but I guess Xorg doesn't do that

01:37 <brentr123[m]> When next stream?

01:45 <alyssa> you really don't want a kernel stream

01:45 <alyssa> ^from me

01:46 <brentr123[m]> I meant Marcus

01:49 <alyssa> oh

01:50 <alyssa> drm_client_modeset "looks" like it does what you want, but it seems to be a fbdev thing...?

02:20 <alyssa> oh. it's a wontfix. xorg doesn't support displayport hotplugging without a DE.

02:21 <alyssa> needs something like https://github.com/phillipberndt/autorandr

02:22 <chadmed> friendship ended with Xorg now wayland is my best friend

06:03 <dottedmag> alyssa: X and atomic modesetting... Not a love at first sight. Have you seen https://github.com/torvalds/linux/commit/26b1d3b527e7bf3e24b814d617866ac5199ce68d ? (also that's why never name your DRM client binary Xtreme)

06:06 <sven> or just set req->value > 1 if your binary starts with X i guess

06:06 <sven> but that's quite a hack. X must've screwed up pretty badly :D

06:29 <ar> dottedmag: wait, so xf86-video-modesetting has broken idea of atomic, and they decide to break atomic for everyone?

06:40 <dottedmag> ar: For every binary with name starting with capital X

06:40 <sven> nah, not everyone. only every process that starts with X! :-P

06:41 <sven> but seriously, enabling a workaround depending on the process name kinda sounds like X messed up in truly horrible ways

07:09 <j_ey> is that actually in the kernel?

07:09 <j_ey> or is it april fools or something

07:09 <sven> pretty sure it's in the kernel

07:10 <j_ey> wow

07:11 <sven> yeah. that's why I assume that X must've messed up pretty badly

09:08 <marcan> amazing

09:08 <marcan> this is windows driver process name hacks level

09:12 <mjg59> Kind of amazed that got in, yeah

09:13 <j_ey> linus must have missed it :P

09:13 <mjg59> Not sure there's an actually better solution, though

09:13 <chadmed> yeah doesnt linus have a thing about userspace stuff imposing itself on kernel decisions? seems like a pretty big thing for him to miss given that

09:15 <ar> chadmed: "don't break userspace, ever"?

09:16 <chadmed> well that but also the obverse. i remember him kicking up a massive stink about lennart trying to get kernel maintainers to change stuff to accommodate systemd's design decisions. maybe i am misremembering

09:18 <ar> yeah, lennart tried to hijack "debug" kernel commandline argument

09:19 <JTL> chadmed: I seem to remember that too?

09:19 <sven> it sounds like this was just a terrible situation with no good solution. and i guess that hack was just the least bad solution in the end

09:20 <chadmed> well i mean we could just all move to wayland and have cute puppies and no more war and hunger :P

09:20 <chadmed> but the green gpus wont let us have those nice things

10:59 <kettenis> ah, I had forgotten all about that gem

11:02 <dhewg> gem of the day: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.10.y&id=825c00c2ee143eff1d869605c318270686f689e0

11:04 <dhewg> I already like it at the "Fixes:" line

11:04 <dhewg> *liked

11:05 <j_ey> lol

11:08 <kettenis> off-topic, but boy it is amazing how Intel keeps pushing out broken hardware

11:08 <chadmed> dhewg: thats filthy lmao. october 18 baby i say goodbye to amd64 forever

11:09 <chadmed> (hopefully)

11:09 <kettenis> there literally isn't any single clock that you can use on x86 systems that isn't broken on some systems

11:10 <kettenis> I think ARM got it spot on with have the architecturally defined timer that includes a register that tells you the frequency it runs at

11:10 <kettenis> (admittedly only with armv7 and later)

11:10 <chadmed> the solution is simple. intel needs to add yet another clock source that is a tiny bit broken in some use cases but fixes the use cases in which the other clocks are broken. its all about "flexibility" after all!

11:37 <ar> i'm reasonably happy with all my private x86 systems, but the only intel chips in them are NICs (wifi or wired) or thunderbolt controllers

11:50 <chadmed> yeah ive been having this discussion with my mates. in the grand scheme of things this stuff doesnt _really_ affect the platform's usability. i type "emerge libreoffice" on both and get a working office suite. its not a matter of being unhappy with the performance of my x86 box, (for me) its more a growing dissatisfaction with the platform's design philosophy.

11:51 <kettenis> well, AMD CPUs and chipsets have similar issues

11:52 <chadmed> yeah wasnt too happy when i found out about the platform "security" processor...

12:40 <arnd> kettenis: The hardware timer is supposed to be there on ARMV7VE (Cortex-A7/A15) or later, but there are enough examples of it being broken in certain SoCs, I don't think there is any hope of ARM being less of a trainwreck in this area than Intel

12:44 <kettenis> arnd: well, so far, in my experience it is less of a trainwreck

12:45 <kettenis> yes, there are hardware bugs, but in most cases they can be worked around

12:46 <kettenis> although I suppose that when I'd try to do more aggressive power management, more bugs will pop up

12:47 <arnd> Documentation/devicetree/bindings/timer/arm,arch_timer.yaml in Linux lists a number of errata for the timer. In most cases this ends up meaning that we can't use it from user space because it's unreliable

12:49 <arnd> also, timer bugs are notoriously hard to find, because you can't rely on the timer to tell you when it goes wrong. One example is the Samsung Exynos, which has a timer that almost always has the correct values, but once in a blue moon produces nonsense

12:49 <arnd> (I assume newer versions fixed it, this was exynos5 IIRC)

12:51 <arnd> I'd also include the way that Apple hooks up the timer to the FIQ in this, regardless of whether this is technically compliant or not

12:57 <psykose> timers must just be very hard for almost every vendor to have a bunch of broken timers

12:57 <psykose> i don't think they intentionally want to consistently have a bunch of broken things every release

13:13 <dottedmag> psydroid: I might be talking out of my ass here, because I really have no clue... But isn't it due to grafting new timer-changing features onto existing ISA? E.g. virtualization and power management change everything related to timers.

14:05 <krbtgt> it's all about implementation