Are you sure you load symbols like "rrPrivKey" ? (these are #define's)

By the way, are you sure you really need them ? These are pretty internal.

Note: if you need to attach your own private data somewhere, you should define your own keys for that (don't abuse anybody else's).

rrPrivKey was a real symbol in video driver ABI versions 4 through 7:

abi4/xorg/randrstr.h:extern DevPrivateKey rrPrivKey;
abi5/xorg/randrstr.h:extern DevPrivateKey rrPrivKey;
abi6/xorg/randrstr.h:extern _X_EXPORT DevPrivateKey rrPrivKey;
abi7/xorg/randrstr.h:extern _X_EXPORT DevPrivateKey rrPrivKey;

It became a define in commit faeebead.

We only support ABIs >= 6 in modern drivers, although I'm trying to raise the minimum eventually.

We do use these symbols for various things in the driver. If you are interested in removing one from the API or have a question about what we need it for, please let me know.

@aplattner What exactly are you using this for ? If it's just for checking whether randr is initialized: i'm going to add a functions for that, which is checking it on per-screen basis. (yes, other drivers are also doing that kind of abuse, since nobody ever cared about adding a proper API for this :()

Can you pleas also check which proc vectors you're calling directly or even hooking ?

@aplattner What exactly are you using this for ? If it's just for checking whether randr is initialized: i'm going to add a functions for that, which is checking it on per-screen basis. (yes, other drivers are also doing that kind of abuse, since nobody ever cared about adding a proper API for this :()

We don't use the xf86 RandR layer, so we need to replace the dispatch functions for X_RRSetScreenConfig, X_RRGetScreenInfo, X_RRAddOutputMode, X_RRDeleteOutputMode, and X_RRGetCrtcInfo and the implementations for these need to reach into the rrpriv for a variety of things such as the Output configuration, last config timestamp, etc. Please make sure you @ me on changes to that interface.

Can you pleas also check which proc vectors you're calling directly or even hooking ?

I think this is every function we wrap and/or call, although it's possible I missed one somewhere if it has weird syntax or something. Not all of these are used in every ABI.

AdjustFrame
BackingStoreFuncs.RestoreAreas
BackingStoreFuncs.SaveAreas
BlockHandler
ChangeWindowAttributes
ClipNotify
CloseScreen
ConfigNotify
ConstrainCursorHarder
CopyWindow
CreateColormap
CreateGC
CreatePixmap
CreateScreenResources
CreateWindow
DestroyColormap
DestroyPixmap
DestroyWindow
DriverFunc
EnableDisableFBAccess
EnterVT
GetImage
GetScreenPixmap
GetSpans
GetWindowPixmap
InstallColormap
LeaveVT
PaintWindowBackground
PaintWindowBorder
PointerMoved
PostValidateTree
PresentSharedPixmap
Probe
ReparentWindow
RequestSharedPixmapNotifyDamage
SaveDoomedAreas
SaveScreen
SetSharedPixmapBacking
SetWindowPixmap
SharedPixmapNotifyDamage
SharePixmapBacking
StartPixmapTracking
StopFlippingPixmapTracking
StopPixmapTracking
StoreColors
SwitchMode
SyncSharedPixmap
ValidateTree
WindowExposures

PaintWindowBackground PaintWindowBorder

These had been removed somewhat 15 years ago. Smells like it's time to remove that ancient stuff ;-)

@aplattner what are you using GetClientFd() for ? Do you really need it ?

@aplattner what are you using SetCriticalOutputPending() for ?

These had been removed somewhat 15 years ago. Smells like it's time to remove that ancient stuff

Yeah, I have a bug open to remove some of the older support from the driver. I just need to round up a list of which distributions we're required to support and which ones are fully EOL. We tend to support even the "extended life" phases of old distributions, so for example RHEL 7 has another three-ish years to go. But even that is using xserver 1.18.

In any case, none of that matters for this upstream project since those ABI versions are frozen and supporting them is only a burden for me.

what are you using GetClientFd() for ? Do you really need it ?

We have a shared memory locking system that allows the server to take the lock immediately if the client has died. Looking at the code, it looks like we use the client fd to do a recv(fd, &b, 1, MSG_PEEK | MSG_DONTWAIT) to see if the client's connection has died without having to wait for the server to process it and set client->clientGone. If we lose access to that, I think the only downside would be that taking the lock would have to time out instead. It's mostly an exceptional condition for when a client dies unexpectedly while holding the lock.

what are you using SetCriticalOutputPending() for ?

We use it as part of a workaround to get consistent ordering of ValidateTree calls in some complicated Xinerama scenarios across multiple devices. I personally want to delete all of our Xinerama support because I hate these workarounds, but I haven't managed to convince management yet that Xinerama is ready to be put to pasture.

We tend to support even the "extended life" phases of old distributions, so for example RHEL 7 has another three-ish years to go.

Does this all need to be in one release ? Why not having LTS branch for the really old systems, that doens't receive anything new but bugfixes only ?

If we lose access to that, I think the only downside would be that taking the lock would have to time out instead. It's mostly an exceptional condition for when a client dies unexpectedly while holding the lock.

Does it really hurt to drop this ? Or maybe should we add an API call for this ? Something like ClientPing() ?

We use it as part of a workaround to get consistent ordering of ValidateTree calls in some complicated Xinerama scenarios across multiple devices. I personally want to delete all of our Xinerama support because I hate these workarounds, but I haven't managed to convince management yet that Xinerama is ready to be put to pasture.

Frankly, haven't seen Xinerama + NVidia anywhere in the field. Instead some of my clients just using those cards with many outputs (those weren't even aware of Xinerama at all). Xinerama in general is getting rare these days. Most use cases should IMHO also work via KMS (not sure whether/how cross-vendor GL then works here).

IMHO, you can drop Xinerama support from your driver.

By the way, there's been talking about a new, fully FOSS driver (IMHO not just the kernel modules, but also mesa side) - is that correct ? What's the status of this ?

@aplattner could you perhaps split the list into which screen proc's you're implementing, which ones you're calling yourself (via the pScreen->* vectors) and what other API functions ?

On the screen proc's: I'm working on putting an end the fragile wrapping. Instead only the Screen driver should set them - anybody else registering hooks, and callers don't call the pointers directly anymore, but using dedicated functions. A first step of that already landed: !1711 (merged).

Then comes !1714, which is adding the hook infrastructure. A vital aspect here is that those hooks are designed to run independently, in unspecified order - the only guarantee is they're running either before (destructors) or after (constructors) the screen's proc.

We don't use the xf86 RandR layer, so we need to replace the dispatch functions for X_RRSetScreenConfig, X_RRGetScreenInfo, X_RRAddOutputMode, X_RRDeleteOutputMode, and X_RRGetCrtcInfo

Uh, why exactly ? You don't directly overwrite protocol handlers (ProcRandrVector), do you ?!

EDIT: a minute ago, got report from xrdp team that exactly that part is a huge trouble maker.

@aplattner what are you using GERegisterExtension() for ?