From info at metux.net Fri May 2 11:09:20 2025 From: info at metux.net (Enrico Weigelt, metux IT consult) Date: Fri, 2 May 2025 13:09:20 +0200 Subject: Xorg: MRs on sbus cleanups Message-ID: <145e288c-b62f-4a26-b13b-62c8d5b79320@metux.net> Hi folks, in case anybody still using sbus-based graphics cards w/ Xorg, please have a look at whether these MRs are okay: * https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1940 -> removes probing for several sbus cards that we don't have any drivers anymore -> we (Xorg) never had a driver for MGX (Quantum3D) cards, so there probably had been some 3rdparty driver * https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1942 -> unexporting a bunch of symbols that no drivers (known to us) are using -> but don't know whether there might be some 3rdparty drivers that really use some of them In any case, help on testing of those HW would be highly appreciated. thx. --mtx -- --- All racism is bad. All lives matter. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info at metux.net -- +49-151-27565287 From info at metux.net Fri May 2 18:22:16 2025 From: info at metux.net (Enrico Weigelt, metux IT consult) Date: Fri, 2 May 2025 20:22:16 +0200 Subject: xf86: VGA arbiter lock on CloseScreen() still needed ? In-Reply-To: <6340a2d8-9f6b-4c94-b739-5e29347ce926@daenzer.net> References: <3669009e-3a9c-4d02-822e-d95598b85aec@metux.net> <6340a2d8-9f6b-4c94-b739-5e29347ce926@daenzer.net> Message-ID: On 29.04.25 15:27, Michel D?nzer wrote: >> In most cases, that's really simple and straightforward, [...] > > That contradicts my experience working on the X server code for over two decades. Sorry, most cases, I've converted so far. (just speaking about what's in that queue) Of course there also are tricky cases, I'll have a closer look at those when it's their time :p My goal right how is decoupling extensions (which are quite orthogonal to screen drivers/DIX). Layered drivers (w/ fb, mi, ...) aren't my focus yet (even though did some cleanup there, too. > There are many cases where the callbacks must be executed in a specific order > for correct operation. Yes, sometimes that's the case. That's what I'm currently decoupling. In most of the cases I've touched so far, it's because the daisy-chaining. > And the driver's callback can be anywhere in that order. *drivers*, yes. My current focus are extensions. But I've already found (and cleaned) several cases of drivers where we don't need that at all, because the call chain actually is determined at compile time (eg. when using MI or FB functions). >> When fully done, it's also now possible hook/unhook at runtime (eg. >> enable/disable extensions on the fly, etc) > > That's already possible, and done. Change hooking at runtime ? How do you do this, when the daisy-chain scattered through lots of devPrivate's ? --mtx -- --- All racism is bad. All lives matter. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info at metux.net -- +49-151-27565287