* feat: forward requested command-line options
The CLI now forwards the `-ac`, `-audit`, `-auth`, `-core`,
`+extension`, `-extension`, `-glamor`, `-listen`, `-nolisten`, and `-verbose` flags
to `Xwayland`. In addition, command-line flags no longer require the
display to be the first parameter. Also the `-help` and `-version` flags
were added, which print the relevant message and return 0.
The match case structure should make it easier to add new arguments if
people have use for them. For example, I chose not to add the `-ld`,
`-lm`, and `-ls` flags since they are dependent on `Xwayland`'s
compile-time flags.
Since the connection handshake establishes the most data a request can
send, if the data length exceeds that limit, we can follow ICCCM 2.7.2
sending the INCR property and continuing to send data via PropertyNotify
events.
To test the changes, we create `XState::set_max_req_bytes` to forcefully
trigger the INCR mechanism in integration test runs with a constant,
substantially less amount of data.
xcb-util-cursor made another patch release to revert back to Rust 2021
edition, so we bump to that.
Also create a function, `timespec_from_millis` to make creating
`Timespec` for using in `poll` calls a lot more ergonomic.
This should simplify how some of the code reads, as well as allowing for future
feature additions to be accomplished in a less restrictive manner. The slotmap +
Object enum pattern was kind of like a really bad ecs in a way anyway. Also I
was looking for an excuse to use an ecs.
Satellite will now force Xwayland to always render with the native
display resolution, and just scale surface sizes accordingly. As a result,
applications won't really respect DPI, but this can be adjusted through
the same means as with normal X11.
Part of #28.
Found a good way to avoid both an extra function to RunData and make calling `xwayland_exit_code` in other RunData types *less* prone to memory violations. Having a function with a non-empty default implementation being overridden by an empty implementation felt too awkward.
This was being used to pass the X11 atoms all over the place, but I
realize this is no longer necessary - we can just pass them directly to
our RealConnection when creating it.
Seems some applications don't expect their popups to be unmapped without
their consent, so they make act strangely, but at least it doesn't
crash.
Fixes#117
Before, every time the clipboard selection changed, satellite would copy
everything on it and force itself to be the clipboard owner, regardless
of X11 or Wayland. Now, satellite is only the owner when the clipboard
owner comes from Wayland, and uses the XFixes extension to watch for
changes in clipboard ownership X11 side. Satellite also now avoids
copying all of the clipboard contents into memory every time, instead
copying directly on request. This is a pretty big change, but should
hopefully help make the clipboard more stable.
Also added some misc test cleanup/using helper functions where possible.
Using the XFixes extension may also end up being necessary for
implementing drag and drop, so it's good the infrastructure is there
now.
