Like I said, I don't know much about it. You are probably correct; it shouldn't be with Vulkan. But I think there are some problems with Wayland, and many things in the X protocol is good (although there are also problems with it).
OK, I looked, and I think you are right; DRI is better. It would work with what my ideas are (and I think SCM_RIGHTS would be used for this purpose too). Handling resize though would just be you can continue to render a picture of the old size and it will be cropped (or if made larger, the X window background will be displayed in the part outside of the DRI picture), or else it may handle the resize event to close the DRI handle and open a new one with the new size if needed.
The protocol would still be independent of the implementation, though. But because DRI involves system-dependent features, this means that the use of DRI is not fully defined in the core protocol. However, that shouldn't be a problem.
SCM_RIGHTS is already used for FD passing for DRI3. Your thoughts on shm_open are already part of the X SHM extension, which has been around for over 25 years now.
Lots of people have ideas for an "X12" that turns out to be stuff already supported by the X11 protocol. Not enough people know about the true problems with X11, or have ever asked us Linux developers think about what needs fixing (hi, I'm a long-time Linux graphics contributor and co-wrote a large part of the Wayland spec). X11 extensions have not been a major problem in 25 years.
Whenever I find myself reading about X11's history my conclusion is always that you guys are heroes. A small group of people keeping an ancient behemoth alive, dealing with plenty of legacy of the kind that drives people to quit jobs.
And when you finally decide you've had enough and go for a rewrite... people shit on you and everyone suddenly knows better.
> Lots of people have ideas for an "X12" that turns out to be stuff already supported by the X11 protocol.
That is true, although many of them are messy in X11. One of these is that the protocol and implementation are tied together more than they should be (one of these problems is server configuration requests, which I think do not belong there). Some of my ideas are:
- Timestamps. The way timestamps work in X11 is messy. A better way is 64-bit timestamps with an unspecified rate; what is specified is that timestamps are monotonic; i.e. if any two requests/responses/events use timestamps, the later one is guaranteed to have a larger number as its timestamp. (However, timestamps might not always increase when the server is grabbed; this is implementation-dependent.)
- Font path configuration. This should not be part of the core protocol; it improperly exposes the directory structure and the font formats. (I do suggest a XSET extension, which is optional, and what settings they set and how are implementation-dependent; the "xset" command would pass its arguments (except -display) to the server, which returns the text which will be the response. This makes it completely general, but a separate specification would provide guidelines for consistency, although not strictly required.)
- Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes. If the suppress screen saver flag is set on any mapped window, then the server should suppress the screen saver. Other than that, how the screen saver is implemented (if at all) and what it does is implementation-dependent, and probably configurable by the user.
- Mouse cursor shapes. My proposition allows the server to substitute its own full colour cursor of arbitrary size and opacity (and maybe even animation) when a client requests a font-based cursor shape (either the standard X cursor font, or some others, depending on what the implementation supports), unless the user disables this feature. Whether or not this is implemented is implementation-dependent, and it is completely independent of the protocol. (Whether or not you get the same image as you would by loading the cursor font with EnableAntialiasing and rendering that character, is also implementation-dependent.) (Substituting cursor shapes is probably not a feature I would use (I like the standard monochrome cursors), but some users will like it, especially those with very high resolution displays.)
- Bells. The core bell request should instead be like XkbBell() (although none of its variants (such as XkbDeviceBell and XkbForceBell etc) are possible). The only thing the server is guaranteed to do is to send a bell event if any clients care; what else it might or might not do is implementation-dependent and would probaly be configurable by the user to some extend. (For example, it may be configurable to suppress the audible bell if the bell event is requested by any client.)
- Allow different screens to have their own keyboard, or to share. Same is true of the mouse, and there may even be more than one mouse per screen (this is to support touch-screens; I don't like touch screens, but some people like it). Clients that don't care can ignore the field which specifies which mouse the event is.
- Use only one endianness rather than two in the protocol, for simplicity. The first byte is "X"; this also enables the possibility (but not the requirement) that a server implementation might support both X11 and X12 clients using the same socket, since you can distinguish between them.
- Some additional standard mouse cursor shapes (in addition to the ones in X11). The cursor font and "Fixed" font are the two "highly recommended" fonts to include in the system. (Some of my suggested new standard cursor shapes include: XC_arrow_plus, XC_arrow_minus, XC_magnify, XC_magnify_plus, XC_magnify_minus, XC_chaos, XC_invisible, XC_stop, XC_no_smoking, XC_xterm_lazy)
Half the stuff in here is already possible in X11. The rest make very little sense.
> - Timestamps. The way timestamps work in X11 is messy.
Well, yeah. Distributed timekeeping is messy. Clients can already retrieve the server's timestamp and keep a rough approximation of what's going on (I wrote a server time estimator for GNOME/mutter). Not sure how you'd fix it. Wayland replaced timestamps with serials.
> - Font path configuration.
Are you familiar with XSETTINGS? It was supported for many years in the toolkits, and got basically no traction.
> - Screen saver configuration. I would have the core protocol has only two things dealing with screen savers: the screen saver event, and the suppress screen saver flag in window attributes.
If you want to propose this as a specification, you're more than welcome to do so -- some sort of EWMH hint like _NET_WM_INHIBIT_SUSPEND or similar. Write up a spec and mail it to wm-spec-list. But you'll probably be told about to use the existing screensaver inhibit spec instead:
A client can already arbitrarily get and set the cursor image for a given cursor name with the XFixes extension, including setting RGBA32 cursor images.
> - Allow different screens to have their own keyboard, or to share.
XInput 2 supports multi-seat just fine.
> - The -retro option should be the default.
Not sure why this requires a whole new protocol version, just compile your X server with it on by default, or configure your display manager to set it.
You seem to be misunderstanding many of my points. (Maybe that is because I am unclear.)
> A client can already arbitrarily get and set the cursor image for a given cursor name...
That is not what I am suggesting at all. My suggestion is: The client only specifies a monochrome cursor, possibly from a font; the server MAY substitute a (possibly animated) RGBA32 (or other colour type) image (for a font-based cursor) IF the user has enabled that feature in the server configuration file.
> Not sure why this requires a whole new protocol version...
Indeed, that is independent of the protocol. I just think it is more useful, is all.
You do need real-time time stamps for some parts of a display protocol, since clients should be able to accurately determine when past frames were displayed, and accurately request display times for future frames (subject to the potential for failure because OS scheduling is not hard real-time).
This is especially true for modern displays which have some limited support for variable refresh rates.
OK, I looked, and I think you are right; DRI is better. It would work with what my ideas are (and I think SCM_RIGHTS would be used for this purpose too). Handling resize though would just be you can continue to render a picture of the old size and it will be cropped (or if made larger, the X window background will be displayed in the part outside of the DRI picture), or else it may handle the resize event to close the DRI handle and open a new one with the new size if needed.
The protocol would still be independent of the implementation, though. But because DRI involves system-dependent features, this means that the use of DRI is not fully defined in the core protocol. However, that shouldn't be a problem.