Remove DGA extension (direct access to raw framebuffer)

[metux]

Describe the idea

drop the DGA extension

• phase 1 (abi 25): drop protocol supports, but leave ABI stubs in place)
• phase 2 (abi 26): also drop the ABI stubs

It should be done because

• DGA was a workaround to allow clients having direct access raw framebuffer memory (userspace HW arbiter!)
• obsoleted by KMS
• security (client has direct HW access!) nightmare and inherently unstable
• client often needed special HW support (eg. as soon as fb layout is a bit unusual, eg. not linear)
• needs root (UID 0) access for both server and clients
• inherently incompatible with lots of things (eg. randr, composite, ...)
• not used anymore
• code base is very unmaintained and would need major refactoring

What are the alternatives?

No response

Additional context

No response

Extra fields

• I have checked the existing New Ideas, RFCs Of The Core Team, Ideas Soon To Be Addressed and Someday Ideas
• I have read the Contributing Guidelines
• I'd like to work on this idea

[metux]

@X11Libre/reviewers @X11Libre/wranglers

[algrid]

A general question regarding all potential feature removals: should we follow a process like

1. Deprecate the feature / turn it off by default
2. Wait for some time, consider any feedback that may come
3. After a while remove the feature completely

Does this make sense or it will be too lucrative and too slow, preventing us from moving forward as fast as we want?

[metux]

In general yes, but in this particular case, it's slowing down other work (eg. request handler refactoring).
And I really wonder whether anybody out there would ever miss it.

[algrid]

Yeah, that particular code looks really ancient. Let's see what other people have to say, I don't really have an expertise to say if it can still be used somewhere or not.

[cepelinas9000]

There was mentioned DGA in SDL, but when started digging I only found it was removed from SDL 1.3 in 2006: libsdl-org/SDL-historical-archive@7975a25 And it is only thing I could quickly search.

[stefan11111]

* DGA was a workaround to allow clients having _direct_ access raw framebuffer memory (userspace HW arbiter!)

* obsoleted by KMS

* security (client has direct HW access!) nightmare and inherently unstable

KMS is not available everywhere, and the security issues created by this might not be a concern for some people who need this.

Are there really no drivers that rely on this?

[pugly-tech]

https://mplayerhq.hu/DOCS/HTML/en/dga.html
it looks like mplayer supports DGA, but it seems unweildly and I don't know how many users use that feature

https://download.nvidia.com/XFree86/Linux-x86_64/304.137/README/faq.html

Why do applications that use DGA graphics fail?

The NVIDIA driver does not support the graphics component of the XFree86-DGA (Direct Graphics Access) extension. Applications can use the XDGASelectInput() function to acquire relative pointer motion, but graphics-related functions such as XDGASetMode() and XDGAOpenFramebuffer() will fail.

The graphics component of XFree86-DGA is not supported because it requires a CPU mapping of framebuffer memory. As graphics cards ship with increasing quantities of video memory, the NVIDIA X driver has had to switch to a more dynamic memory mapping scheme that is incompatible with DGA. Furthermore, DGA does not cooperate with other graphics rendering libraries such as Xlib and OpenGL because it accesses GPU resources directly.

NVIDIA recommends that applications use OpenGL or Xlib, rather than DGA, for graphics rendering. Using rendering libraries other than DGA will yield better performance and improve interoperability with other X applications.

https://bbs.archlinux.org/viewtopic.php?id=184905
Disabling part of it helped an Arch user in 2014

It sounds like it might sometimes be used to determine cursor position in some scenarios, but xlib should be used instead. Is it possible that DGA is doing some auxiliary functions, and it can be stripped down to just those functions?

[callmetango]

My take on this: Once we have "enough" (social) media reach we can also ask our users what they still need. Doing this by ourselves would be very tedious and nearly impossible, but our users know. I am thinking of something like the Linux kernel folks do once in a while: They announce a deprecation of some subsystem and wait whoever complains. If there is no one then scrap it.

We could also try this right now but have to be careful communicating that we like to hear who still uses it instead of giving the impression that we are destroying X11 in any way.

[VJSLH]

I think maybe you should approach it from the angle of declaring it to be an orphaned project first, see if anyone is interested in taking up maintenance or code cleanup. Come up with a time frame before later stating that it will be deprecated. Once you announce your plans to deprecate it, give a short time period before going through with it, so people can make clear if they have any qualms with the deprecation. I think that it should be a tiered approach basically.

[metux]

okay, let's declare it deprecated with next release. and drop it with the one coming after.

the biggest blocker is now gone due DGA-1.0 removal, the remaining stuff (DGA-2.0) is easier to maintain.

[stefan11111]

the biggest blocker is now gone due DGA-1.0 removal, the remaining stuff (DGA-2.0) is easier to maintain.

In that case, do we still need to remove DGA-2.0?

[metux]

not pressing anymore.

[callmetango]

The support for the DGA 1.0 protocol has been removed in xfree86: dga: drop support for old DGA 1.0 protocol by metux · Pull Request #842 · X11Libre/xserver.