-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathTODO
More file actions
63 lines (63 loc) · 7.68 KB
/
Copy pathTODO
File metadata and controls
63 lines (63 loc) · 7.68 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
Remove HashMaps usage when the key is an integer. Iterating an array is faster.
Support BIG-REQUESTS extension.
Use auth if there is one added in xauthority file for the path (X1 is \$USER/unix:1)
and validate client connection against it. Right now we accept all connections.
Use epoll equivalent on other OS'.
Move protocol definition and request/reply handling to a separate repository as it can also be used for a zig native x11 client.
Implement xc-misc extension, might be needed in practice for gtk/qt applications that spam new resources every frame.
Use composition by default, but if any application gets the overlay window with GetCompositeOverlayWindow then turn it off until the composite overlay window is released.
Maybe break x11 protocol standard and use the top 3 bits in resource id?
Handle error.InvalidEnumTag in request.read_request using std.meta.intToEnum. It should return an x11 .value error.
Move backend to a separate process which has can be restarted. Restarting works without losing graphics contexts since pixmaps save the dmabuf fd, which it can re-import if the backend process is restarted.
Then we can use process restriction functions for increased security.
Instead of creating and destroying opengl textures for each window/pixmap each time, create textures and re-use them; never destroying them.
This is more efficient and leads to lower memory usage (nvidia leaks memory on texture create/destroy, on purpose).
Client might set any of the top resource id bits to 1. What do?
Replace all std.meta.intToEnum with a more efficient variant that does a direct cast if the value is in range, without iterating all enum values (if the enum has ordered values).
glxGetVisualConfigs and glxGetFbConfigs doesn't seem to return the correct amount of data? glxinfo shows less data than we return.
If writing data to client buffer fails partially (is that possible?) then discard the bytes written so we dont send partial data to client.
Go through all requests and make sure they are all implemented correctly as according to the spec and make end-to-end tests for all of them and unit tests as well.
Vulkan applications (vkcube) spam dri3 requests in render, but not with the xorg server. Why?
Get current tty with /proc/self/stat, see `man proc_pid_stat`.
When implementing reparent consider that the client might attempt to reparent a window to one of its children (or grandchildren) or itself. Handle that case according to spec.
When SelectInput is added in more extensions then handle case when attempting to use an event id that belongs to another extension.
Optimize allocation strategy in request handler. Right now it uses an arena and all lists are allocated on heap as arrays.
Since requests have a known size we could allocate one block of memory once and add the data to that.
The size could be extended based on required alignment and padding of structs (calculate size with sizeof).
If GrabServer is really needed to prevent race conditions on resource get/set then maybe instead make GrabServer lock resources accessed by the client.
Maybe instead of locking the resource, make the resource read-only (silently ignore set operations) for other clients, or delay the set operation
until UngrabServer is called, if the GrabServer client didn't do a set operation on a resource that it did get on.
Add option to only allow clipboard read for applications after ctrl+v is pressed in the application, for the next 2-3 seconds or until XSetClipboardOwner is called again.
Use io_uring for data and sendmsg/recvmsg for file descriptors.
Preallocate capacity in write reply/error/event.
Compositors could be made to work automatically with multiple monitors by handling overlay window differently (or maybe do it for all applications):
Dont sync swapBuffers directly to display, instead do triple buffering where they update the buffer directly
and pause the present event until the timing is good to process the next frame.
To get msc and ust use drmCrtcGetSequence. The sequence is the msc and ust is the ns divided by 1000.
If that fails then use drmWaitVBlank relative with 0 sequence, see ms_get_kernel_ust_msc in the xserver.
drmWaitVBlank is 32-bit and needs to be converted to 64-bit, see how it's done in xserver ms_kernel_msc_to_crtc_msc.
drmCrtcGetSequence was added in linux 4.15 released on 28 Jan 2018, so maybe drmWaitVBlank is not needed?
If the drawable isn't inside any monitor then return ust = microseconds from clock_gettime(CLOCK_MONOTONIC),
and msc with a fake value, see: present_fake_get_ust_msc in the xserver.
Dont create an opengl texture for windows. Dont create opengl textures for every pixmap, only do that if the window has no other pixmap(?).
Move read_request data size check (header size vs actually read size) to request.zig instead of client.zig.
Replace fifo with the new io interface.
Maybe move read/write x11 network transfer to another thread.
Add option for client windows to advertise that they should be in the overlay plane. The server should set a property on the window to indicate which plane it is actually on.
Create InputX11 and use that when running nested.
Go through all events defined in the protocol (core and extensions) and check if they are called (called at all and with the right arguments).
Add an option to disable middle mouse paste (make SetSelectionOwner with atom PRIMARY have no effect).
Maybe allow global hotkeys as long as the application does a grab. If it does a grab other applications dont receive input so there is no hidden keylogger that silently listens to keys.
Support multiple monitors in nested mode. This is useful for testing (both phoenix and client applications).
Make pixmap reference counted. This is needed for PresentPixmap as it shouldn't get deleted immediately even if FreePixmap is called, it should instead be deleted after it has been rendered.
ConnectorType and SignalFormat Randr properties are declared as mandatory in the Randr protocol but they aren't always set by the Xorg server. Are they really mandatory? We don't currently set them in phoenix.
Implement a screen recording x11 extension (zero copy) and use it in gpu screen recorder as well. Also modify an existing desktop portal and add support for that there to make other applications (such as obs, discord, etc) be able to record monitors efficiently.
When TILE support is added consider this: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4154#note_3249071 SRC_X drm property doesn't work on nvidia.
When damage/expose tracking is added have a keybind to toggle showing updated regions (flash red rectangle).
Trigger KeymapNotify (for FocusIn).
Support reading/writing file descriptors automatically in request/reply parsing. If field type is std.posix.fd_t then handle it as a file descriptor instead. fd_t may not work as its just an alias to an integer type. May need to create a custom Fd type.
Permissions (for example for selecting for key input) should check if the target window was created by the same client process id. Maybe also allow access to parent/child process windows.
Use Server.set_client_muted when a reply requires a lot of data to be sent, such as GetImage with the root window (capturing a screenshot of all windows). The raw image for one 4k image is 23mb (rgb). In such cases we want to force the client to receive the data before doing anything else with the client that requires more data to be allocated.
Call eglReleaseThread after eglTerminate.
Create a more efficient intToEnum that checks if the enum values are sequential (take into consideration exhausive enum) and does a cast directly if they are, otherwise call intToEnum.
Remove rendering to window. Instead render pixmaps directly. Texture blits are expensive on slow (embedded) hardware.