We're left-shifting the bits but weren't comparing against the l_r_l mask
itself. So if we get a sequence of [1, 1, 0, 1] we didn't detect a wobble
because 0b1101 != 0b101 (what we're looking for).
Fix this by turning it into a right shift, that way the bits fall off
the mask automatic
Collect libinput events together with the evdev events and print them to the
log. This makes it possible to debug the full behavior of a user's machine
rather than having to replay it with potential different race conditions/side
effects.
Example event output:
- evdev:
- [ 2, 314443, 4,
This adds a new protocol to negotiate server- and client-side rendering of
window decorations for xdg-toplevels. This allows compositors that want
to draw decorations themselves to send their preference to clients, and
clients that prefer server-side decorations to request them.
This is inspired b
‐‐‐ Original Message ‐‐‐
On March 11, 2018 10:17 PM, Quentin Glidic
wrote:
>
> >
> > > Last but not least: it should be much much clearer that the compositor
> > > is in charge here. This is not about magic SSD, clients must support CSD
> > > in all cases and should not error out if t
On 3/11/18 9:49 PM, Simon Ser wrote:
[snip]
+
+
+
+ This interface permits choosing between client-side and server-side
+ window decorations for a toplevel surface.
+
+ A window decoration is a user interface component used to move, resize
and
+ change a window's state
On March 3, 2018 12:14 PM, Quentin Glidic
wrote:
> On 3/2/18 4:33 PM, Simon Ser wrote:
> > This adds a new protocol to negotiate server- and client-side rendering of
> > window decorations for xdg-toplevels. This allows compositors that want
> > to draw decorations themselves to send their prefer
This new protocol description is a vast simplification over v2, highlights
are:
- All pre-edit text styling is gone, the protocol doesn't seem the place
to convey UI state. Clients are in better knowledge of how to make the
pre-edit string distinguishable from regular text.
- No input panel (OS
