Re: RFC: Wayland high-resolution wheel scrolling
On 6/4/19 02:11 , Simon Ser wrote: On Wednesday, April 3, 2019 5:36 AM, Peter Hutterer wrote: I've been trying to sort out the new hi-res wheel scrolling that was added to linux 5.0 but it's been a bit of a struggle to say the least. For the impatient, skip forward to the protocol diff but the background info is important. Thanks for taking the time to write this big summary. It's pretty helpful! Everything below applies equally to horizontal and vertical scrolling, both directions and wheels and wheel tilts. The APIs that are involved for low-resolution wheel scrolling: kernel: - REL_WHEEL for every wheel click libinput uses pointer axis events for wheels: - pointer axis value: the movement of the wheel in degrees - pointer axis discrete value: the number of wheel clicks - pointer axis source: set to 'wheel' Usally this means you get discrete 1, value 15 for the standard 15-degree mouse wheel, discrete 2 value 30 is two wheel clicks within one hw frame. There is one implicit assumption here: the discrete value must be 1 or more for every event. Otherwise it's impossible to use the value and calculate the angle. More on that later. This API is effectively the same in the wayland protocol except for the unit of the 'value' which is is in screen coordinates, not degrees. wayland protocol: - pointer axis value: the movement in screen coordinates - pointer axis discrete: the number of wheel clicks - pointer axis source: set to 'wheel' The big difference here though: libinput's API is per-device, wayland's API is per wl-seat pointer. There's no way to tell in the protocol that you're scrolling simultaneously with wheels on two different mice. Let's see how the common compositors implement this: weston: - for source wheel, only the discrete value is handled and: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is always (discrete * 10) - otherwise the libinput pointer value (degrees) from a source wheel is ignored The magic multiplier 10 is afaik for historical reasons, weston used to do 10 so early libinput took that. When libinput switched to use physical dimensions instead of 10, that value was kept for backwards compatibility with existing wayland clients. mutter: - for source wheel, only the discrete value is handled and: - clutter-internal event for the discrete **direction** from libinput - i.e. discrete > 1 will still only generate one event,some events drop to the floor here for fast wheel movements - clutter-internal event with (value * 10) marked as 'emulated' but that event is ignored later when we're writing to the protocol - the discrete event is written as wl_pointer.axis_discrete and wl_pointer.axis with a value of 10 So, the same multiplier of 10 but fast scroll events with more than one click per frame appear to get dropped. kwin (through qtwayland): - doesn't handle discrete at all afaict - pointer axis events are passed through but I got a bit confused over the actual value written on the wire here. wlroots: - pointer axis discrete is sent as-is from libinput - pointer axis source is sent as-is from libinput - pointer axis value is sent as-is from libinput Because the physical angle is passed on from libinput as screen coordinates, this means wlroots has different scroll behaviour to GNOME/sway and it does scroll a larger distance for wheels with higher click angles. This is the opposite of the intended behaviour, manufacturers advertise these wheels as slow-scrolling wheels. Realistically though the physical movements is the same-ish and if a client uses discrete it doesn't matter anyway. Hmm, that's interesting. We wlroots devs have had assumed you'd want a given angle to always scroll the same amount of pixels. But this doesn't matter that much because we have a configuration option for the scroll multiplier anyway. We still should have good defaults of course. first, apologies if i got some of the details wrong, I hope the overall summary is still correct enough :) the thing with the angle in this case is that you cannot really decide that angle. The wheel forces you to whatever it's built as and that's it (more recent high-res wheels excepted). Even the earlier free-floating wheels still only send events every X degrees. Users (and manufacturers) thus don't think as angles as much as wheel clicks. A 20 deg wheel feels slower than the standard 15 deg wheel simply because you have to scroll more to get one click. And that's what's advertised too. The angle == pixels mapping makes sense for a continuous axis, I'm not sure it's as useful for the wheel as we have them. Then again, it's relatively niche and only a small subset of users notice and/or care about this particular issue. xf86-input-libinput: - X devices need to set up a scroll distance for scroll motion, the driver uses 120 (since Feb, before it was 15). This means any multiple of 120.0
Re: weston rdp black screen
I am using weston master, freerdp master, and wayland-protocols master I am launching like this: weston --rdp4-key ~/devel/weston/key/rdp-security.key --backend=rdp-backend.so --debug Connecting using 640x480x32, black screen. Can anyone confirm rdp-backend is actually working?? > On Apr 3, 2019, at 13:13, Jean-Francois Dagenais > wrote: > > Hi all, > > I am working on weston on yocto. Amongst other things I have created a meson > version of the weston recipe found in poky. > > Either on my embedded platform or on my PC. Whenever I try to use the rdp > backend, whether as the root compositor or through the [screen-share] > command. I > get a black screen. Input works though and I can blindly click on the > weston-terminal icon, then type commands and proved it works by issuing > "killall > weston" ;) > > I have tried all the RDP clients at my disposal on mac (CoRD, microsoft's rdp > v8 > and v10). > > I get a different behaviour on microsoft' remote connection on windows itself. > Weston logs show: [15:42:10:184] [1809:1809] > [ERROR][com.freerdp.core.transport] > - BIO_read returned a system error 11: Resource temporarily unavailable and > the > client shows a microsoft style error box with no info in it. > > I have no experience with freerdp and need any clues as to what to do to find > the problem. > > ANY pointers what so ever will help me. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
wayland-protocols scope and governance
I've written up a governance document for us to bikeshed, which is included at the end of this email. Some comments upfront. Logistical notes: - We'll need a wayland-protocols mailing list. This should probably be members only, to reduce noise. - Members will be given push access to the upstream repo. We'll live with a gentleman's agreement to play by the rules and invoke the member removal process if someone doesn't play nice. - Someone needs to flesh out the website to show adoption and protocol acknowledgement status. Simon was working on something here: https://gitlab.freedesktop.org/wayland/wayland.freedesktop.org/merge_requests/3 In the interest of keeping this effort moving forward, here are some actionable tasks we can do, in no particular order: - Iterate on this document, or propose a new one - Establish initial membership and status of each protocol 1. State your intention to be a member, including your point of contact and justification per section 1.1, or objection to section 1.1's requirements 2. State your project's approval status & statement for any protocols you care about - Mention any important/interesting implementations of the protocols you care about - Decide how & when to ratifiy the new governance model Aside: wlroots-based compositors have agreed to join under one joint membership, but given that this reduces our voting power, we may at some point dissolve into our constituent members if necessary. I think in practice we'll all get along amicably enough that this won't be a problem. Thoughts? wayland-protocols governance This document governs the maintenance of wayland-protocols and serves to outline the broader process for standardization of protocol extensions in the Wayland ecosystem. 1. Membership Membership in wayland-protocols is offered to stakeholders in the Wayland ecosystem who have an interest in participating in protocol extension standardization. 1.1. Membership requirements a. Membership is extended to projects, rather than individuals. b. Members represent general-purpose projects with a stake in multiple Wayland protocols (e.g. compositors, GUI toolkits, etc), rather than special-purpose applications with a stake in only one or two. c. Each project must provide an individual point-of-contact for that project who can be reached to discuss protocol-related matters. 1.2. Becoming a member a. New members who meet the criteria outlined in 1.1 are established by invitation from an existing member. Projects hoping to join should reach out to an existing member asking for this invitation. b. New members shall write to the wayland-protocols mailing list stating their intention of joining and their sponsor. c. The sponsor shall respond acknowledging their sponsorship of the membership. d. A 14 day discussion period for comments from wayland-protocols members will be held. e. At the conclusion of the discussion period, the new membership is established unless their application was NACKed by a 1/2 majority of existing members. 1.3. Ceasing membership a. A member may step down by writing their intention to do so to the wayland-protocols mailing list. b. A removal vote may be called for by an existing member by posting to the wayland-protocols mailing list. This begins a 14 day voting & discussion period. c. At the conclusion of the voting period, the member is removed if the votes total 2/3rds of members. d. Removed members are not eligible to apply for membership again for a period of 1 year. e. Following a failed vote, the sponsoring member cannot call for a re-vote or propose any other removal for 90 days. 2. Protocols 2.1. Protocol namespaces a. Namespaces are implemented in practice by prefixing each interface name in a protocol definition (XML) with the namespace name, and an underscore (e.g. "xdg_wm_base"). b. Protocols in a namespace may optionally use the namespace followed by a dash in the name (e.g. "xdg-shell"). c. The "xdg" namespace is established for protocols useful for implementing desktop-like systems. d. The "wp" namespace is established for protocols generally useful to Wayland implementations (i.e. "plumbing" protocols). e. The "ext" namespace is established as a general catch-all for protocols that fit into no other namespace. 2.2. Protocol inclusion requirements a. All protocols found in the "xdg" and "wp" namespaces at the time of writing are grandfathered into their respective namespace without further discussion. b. Protocols in the "xdg" and "wp" namespace are eligible for inclusion only if ACKed by at least 3 members. c. Protocols in the "xdg" and "wp" namespace are ineligible for inclusion if if NACKed by
Re: Stepping down as release manager
On Friday, April 5, 2019 4:51 PM, Derek Foreman wrote: > I no longer have as much time to dedicate to this as I used to, so I > think it would be best if someone else could take over managing the > releases for Weston and Wayland. Hi Derek, Thanks for your hard work, it is much appreciated. Regarding the need for a new release manager for Wayland, I'd like to step in and volunteer for this role. I'm willing to take the time necessary to (1) learn the current release process and (2) apply it if the community is interested. Simon Ser ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: Wayland high-resolution wheel scrolling
On Wednesday, April 3, 2019 5:36 AM, Peter Hutterer wrote: > I've been trying to sort out the new hi-res wheel scrolling that was added to > linux 5.0 but it's been a bit of a struggle to say the least. For the > impatient, skip forward to the protocol diff but the background info is > important. Thanks for taking the time to write this big summary. It's pretty helpful! > Everything below applies equally to horizontal and vertical scrolling, both > directions and wheels and wheel tilts. > > The APIs that are involved for low-resolution wheel scrolling: > > kernel: > - REL_WHEEL for every wheel click > > libinput uses pointer axis events for wheels: > - pointer axis value: the movement of the wheel in degrees > - pointer axis discrete value: the number of wheel clicks > - pointer axis source: set to 'wheel' > > Usally this means you get discrete 1, value 15 for the standard 15-degree > mouse > wheel, discrete 2 value 30 is two wheel clicks within one hw frame. > > There is one implicit assumption here: the discrete value must > be 1 or more for every event. Otherwise it's impossible to use the value and > calculate the angle. More on that later. > > This API is effectively the same in the wayland protocol except for the unit > of > the 'value' which is is in screen coordinates, not degrees. > > wayland protocol: > - pointer axis value: the movement in screen coordinates > - pointer axis discrete: the number of wheel clicks > - pointer axis source: set to 'wheel' > > The big difference here though: libinput's API is per-device, wayland's API is > per wl-seat pointer. There's no way to tell in the protocol that you're > scrolling simultaneously with wheels on two different mice. > > Let's see how the common compositors implement this: > > weston: > - for source wheel, only the discrete value is handled and: > - pointer axis discrete is sent as-is from libinput > - pointer axis source is sent as-is from libinput > - pointer axis value is always (discrete * 10) > - otherwise the libinput pointer value (degrees) from a source wheel is > ignored > > The magic multiplier 10 is afaik for historical reasons, weston used to do 10 > so early libinput took that. When libinput switched to use physical dimensions > instead of 10, that value was kept for backwards compatibility with existing > wayland clients. > > mutter: > - for source wheel, only the discrete value is handled and: > - clutter-internal event for the discrete **direction** from libinput > - i.e. discrete > 1 will still only generate one event,some events > drop to the floor here for fast wheel movements > - clutter-internal event with (value * 10) marked as 'emulated' but > that event is ignored later when we're writing to the protocol > - the discrete event is written as wl_pointer.axis_discrete and > wl_pointer.axis with a value of 10 > > So, the same multiplier of 10 but fast scroll events with more than one click > per frame appear to get dropped. > > kwin (through qtwayland): > - doesn't handle discrete at all afaict > - pointer axis events are passed through but I got a bit confused over the > actual value written on the wire here. > > wlroots: > - pointer axis discrete is sent as-is from libinput > - pointer axis source is sent as-is from libinput > - pointer axis value is sent as-is from libinput > > Because the physical angle is passed on from libinput as screen coordinates, > this means wlroots has different scroll behaviour to GNOME/sway and it does > scroll a larger distance for wheels with higher click angles. This is the > opposite of the intended behaviour, manufacturers advertise these wheels > as slow-scrolling wheels. Realistically though the physical movements is the > same-ish and if a client uses discrete it doesn't matter anyway. Hmm, that's interesting. We wlroots devs have had assumed you'd want a given angle to always scroll the same amount of pixels. But this doesn't matter that much because we have a configuration option for the scroll multiplier anyway. We still should have good defaults of course. > xf86-input-libinput: > - X devices need to set up a scroll distance for scroll motion, the driver > uses 120 (since Feb, before it was 15). This means any multiple of 120.0 > triggers legacy button emulation in the server, otherwise the number has no > meaning. > - for source wheel it uses the discrete value only, so effectively 120 * > discrete. > > This driver had a division by 0 for discrete values of 0, fixed in the > current release. More on this later. > > > > Let's look at how wheel events are processed in some of the clients: > > GTK: > - for a discrete event, GDK_SCROLL_UP is passed on flagged as 'emulated' > - the axis value is passed on as GDK_SCROLL_SMOOTH > > Qt: > - doesn't handle discrete > - multiplies the value by -12. This gives it a 120-based value which > matches the Windows API provided the axis value is 10 of course. > Qt on wlroots is probably off here. > > Xwayland: > - X
Re: Stepping down as release manager
On Fri, 5 Apr 2019 at 14:52, Derek Foreman wrote: > I no longer have as much time to dedicate to this as I used to, so I > think it would be best if someone else could take over managing the > releases for Weston and Wayland. Thanks for everything Derek! Really appreciate what you've done over the past couple of cycles. :) Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Stepping down as release manager
Hi everyone, I no longer have as much time to dedicate to this as I used to, so I think it would be best if someone else could take over managing the releases for Weston and Wayland. Thanks for the opportunity to help out, Derek ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
