[ANNOUNCE] libinput 1.11.3
libinput 1.11.3 is now available. There's only a single change that affects users - the HP Chromebook 14 now has the correct pressure ranges applied. All other changes are merely documentation updates (in case anyone reads the release-specific docs). And the libinput-replay tool was updated to set the INPUT_PROP_* bits on startup but most users never need that tool so the impact here is quite limited. Jeremy (1): Improve HP Chromebook 14 pressure ranges Peter Hutterer (9): doc: add the switches page to a "other devices" category doc: libinput-measure is a section, not a subsection doc: add a subsection on how to use libinput record --autorestart data: add HP Chromebook 14 pressure ranges tools: libinput-replay: set INPUT_PROP_* properties on the device README: add a user documentation section fairly high up doc: add a section to the FAQs "is libinput required for Wayland" tools: always set the log handler for debug-events and debug-gui libinput 1.11.3 git tag: 1.11.3 https://www.freedesktop.org/software/libinput/libinput-1.11.3.tar.xz MD5: df6e877f11de4a9793511e9abfe7ef01 libinput-1.11.3.tar.xz SHA1: 68266672fb8bfb0b8e2c4288d7c2be3334e47cc5 libinput-1.11.3.tar.xz SHA256: f31191d96e425b4f16319842279d65946d9d983dcd3d9e466ae1206aa10ecb06 libinput-1.11.3.tar.xz SHA512: 5e18daab6202bcbfddeebc35dac4cabb5f726b5b73f5fc87975b58f3019a54a4b1f506a3200e920638fb978a0b96c23c2e90b081942f86d33c16d4836949 libinput-1.11.3.tar.xz PGP: https://www.freedesktop.org/software/libinput/libinput-1.11.3.tar.xz.sig signature.asc Description: PGP signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC libinput] dox: switch to sphinx for the user-visible documentation
On Tue, Jul 24, 2018 at 09:27:51AM +0100, Daniel Stone wrote: > Hey, > > On Tue, 24 Jul 2018 at 06:43, Peter Hutterer wrote: > > Sending this out as patch even though what really matters is the > > output. Which is... here, tadaaa! > > > > https://people.freedesktop.org/~whot/libinput-rtd/ > > > > Basically the motivation here is to make the user-visible documentation less > > awful, especially because these days, 90% of the doc needs are by end users, > > not the developers. The API itself is just fine in doxygen, but for prose > > doxygen's "Related Pages" features is not perfect. > > > > So I'm wondering if using RTD-style documentation is a better option here. > > This patch is a more-or-less 1:1 conversion of the hand-written > > documentation to use sphinx with the RTD theme. For a good chuckle, look at > > the awk/sed script. (that script would go away anway after the one-time > > conversion to an .rst source format). > > Makes sense, and this does look really good, but ... did you remember > to run the script? The output at the URL above is full of @ref, @dot, > etc. The rest looks good though. :) I'm all for something like Sphinx > - not because I've ever used it or know any of its pros and cons, but > it seems like a more stable tooling which is also more widely used. oh right, the issues here are because this is the README.md which is the only file that doesn't filter through the sed/awk script. Other pages render correctly with the odd exceptions here and there. Doxygen allows @ref\nfoo but my sed script doesn't handle that case correctly. Cheers, Peter ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged
Hey, On Tue, 24 Jul 2018 at 22:45, Derek Foreman wrote: > On 2018-07-22 05:55 AM, Daniel Stone wrote: > > I take it the problem is that the client sets a particular surface as > > the pointer surface, loses focus, sets the same surface as the pointer > > surface on re-enter after not changing the content, and then the > > content is never shown? > > That's my understanding of what I'm seeing, yes. > > Note that it only happens when the cursor can be placed in the cursor > plane (ie: it's wayland_shm). > > The old cursor continues to be shown - if I move into an EFL client from > the desktop, the desktop cursor arrow is sometimes unchanged. > > I do get a surface enter for my pointer surface, though. > > I'm reasonably confident the first time I saw this I would get no cursor > at all on re-enter, but now I get the existing cursor. Though sometimes > it updates to my client cursor, despite no damage or new buffer attach > on the surface. To be fair, this has changed a fair bit with atomic, so I'm not surprised it's different in master. But I am a bit disappointed it's not perfect yet. ;) Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC weston] clients: Don't attach a buffer if mouse cursor surface is unchanged
On 2018-07-22 05:55 AM, Daniel Stone wrote: > Hey Derek, > > On Thu, 22 Feb 2018 at 22:16, Derek Foreman wrote: >> Keep track of what cusor image buffer is attached to the cursor >> surface and avoid re-attaching it if we don't have to. >> >> This isn't just an obviously pointless optimization, it turns all >> of toy toolkit into a test case for handling this properly. >> >> Signed-off-by: Derek Foreman >> --- >> >> Continuing my streak of posting unpopular patches, this patch breaks >> weston, so I'm not pushing for inclusion, but I think we need to >> resolve why it breaks, and fix either weston or wayland documentation >> to reflect expected behaviour. >> >> I think this can be attributed to a weston bug, and we should be able to >> expect that the compositor will be able to redisplay the surface without >> needing to attach a new buffer, and that if the compositor has released >> the buffer then it has a kept copy somewhere... >> >> Any other opinions? > > Hmm, I'm really not sure what to think about this. > > I take it the problem is that the client sets a particular surface as > the pointer surface, loses focus, sets the same surface as the pointer > surface on re-enter after not changing the content, and then the > content is never shown? That's my understanding of what I'm seeing, yes. Note that it only happens when the cursor can be placed in the cursor plane (ie: it's wayland_shm). The old cursor continues to be shown - if I move into an EFL client from the desktop, the desktop cursor arrow is sometimes unchanged. I do get a surface enter for my pointer surface, though. I'm reasonably confident the first time I saw this I would get no cursor at all on re-enter, but now I get the existing cursor. Though sometimes it updates to my client cursor, despite no damage or new buffer attach on the surface. > If so, the two solutions would be: > - the surface content should be preserved across leave/enter; Weston > is buggy for not showing the content on re-enter > - mouse leave and your surface no longer being shown as a pointer > surface causes the surface to lose that role; Wayland protocol spec > should explicitly state this Does losing the role imply the content is removed from the surface? If so, yes, these are the only two options I can think of. > I have a very slight lean towards the latter because it more closely > matches my recollection of what the XDG roles do. But that > recollection might be totally wrong, who knows. I have no strong preference, though I won't have to fix my client code to deal with the former. ;) > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] simple-dmabuf-drm: use GBM generic calls
Hi everyone, On 11 July 2018 at 09:33, Daniel Stone wrote: > Hi, > On Wed, 11 Jul 2018 at 09:16, Pekka Paalanen wrote: >> On Tue, 10 Jul 2018 17:53:15 +0200 Emilio Pozuelo Monfort >> wrote: >> > No need to write libdrm driver specific code for each supported >> > driver, we can just let GBM call the right one for us now. >> > >> > Signed-off-by: Emilio Pozuelo Monfort >> > --- >> > >> > Hi, >> > >> > This simplifies the code a lot, using gbm_bo as Emil suggested. Some >> > problems >> > I still see: >> > >> > - NV12 doesn't work, it seems that >> > backends/dri/gbm_dri.c:gbm_format_to_dri_format() >> > doesn't support it. >> >> I think NV12 and other less common formats, should someone add them in >> this program, should not be lost. That may be part of the reason GBM >> wasn't used: the need to test YUV formats, and non-GPU-renderable >> formats in general. > > Honestly, most of the reason was because I wrote the original client > in about 15 minutes on a very short bus trip. You can probably see > that in comments like 'XXX: would be nice to draw something that > changes here'. So I don't think you can really read too much into the > original code. > > Other great reasons include: > - we wanted to explicitly get modifiers allocated, and this was > before the GBM modifiers interface existed > - at the time, I was doing bring-up of a GBM implementation which > wasn't usable by generic clients (privileged allocation only) > - YUV format support > > I'm pretty ambivalent about it though. V4L2 and Vivid might well cover > the YUV case well enough, and even if not, GBM should still be able to > allocate R/RG buffers. > Darn, I did not spot NV12 in weston. Mesa is perfectly capable of using YUV formats, so it should be a matter of adding the odd GBM bits. That said, it might be more involving than what you have time for, so feel free to put this patch on hold. Thanks Emil ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v4 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol
On Thu, 12 Jul 2018 18:15:32 -0400 Simon Ser wrote: > > Provides the ability to emulate keyboards by applications. Complementary to > > input-method protocol. > > > > The interface is a mirror copy of wl_keyboard, with removed serials, and > > added > > seat binding. > > > > --- > > > > Hello, > > > > thank you for giving me a lot of useful feedback in the last round. I > > applied > > the suggestions and this is the new incarnation of the protocol. Changes to > > v3, > > in no particular order: > > > > - added clarification to the destructor namespaced enum references made > > virtual > > - keyboard creation non-fatal > > > > The responses about keeping a virtual keyboard on a separate connection and > > about using protocol errors as part of the authentication mechanism were > > all in > > agreement, and they made sense to me too. As a result, there is a whole new > > mechanism for that. > > > > The client now requests a creation of a virtual keyboard, but does not > > immediately get a valid instance. It must wait for one of two events in > > virtual_keyboard_manager: `virtual_keyboard_create_failed` for a failure or > > `virtual_keyboard_created` for success. I deliberately kept them inside the > > manager instead of virtual_keyboard, since I don't like the idea of > > creating an > > object and immediately sending a message that it's useless (in case of > > failure). > > > > I also deliberately kept the names long in order not to forget what's being > > manipulated. > > > > The serial number is there to match up requests on different seats with > > failures. I imagine that a compositor might spam the user(s) with a number > > of > > permission requests for different seats, and the user would deal with them > > in a > > random order. Serials prevent the answers from getting mixed up. > > > > I am not happy only with one aspect of this: the amount of time between > > create > > request and response is indefinite, opening a loophole for the compositor > > never > > to reply. I decided that it doesn't warrant a protocol error however. > > > > As usual, feedback is welcome. > > Hi, > > Sorry for the delay. > > I'm not sure I like this new design. > > First, this is using server-side created resources (the a `new_id` argument in > an event). One should be really careful when doing so, see Pekka's post on the > matter [1]. > Thanks, this was an insightful read. If not in this protocol, this kept me from making mistakes in my input-method revision. > Then, this serial mechanism makes me uneasy. A more idiomatic approach would > be > to use a proper object for this. > Do you mean an object defining that an attempt was made, a sort of "creation_attempt" which would later receive the result of the attempt? > Finally, I'm not even sure this security mechanism belongs here. I think > adding > this mechanism to potentially all privileged protocols will result in > duplicated > code and "pollutes" protocols. Here are some other solutions: > > * Have one keyboard daemon they spawn themselves. In this case they can only > expose this interface on the daemon's display. This is e.g. weston's > approach > for its private protocols, and will be sway's approach for privileged > protocols. > * Allow other clients to use this interface too, but don't let them know if > the > keyboard they created is active or is ignored. This could possibly lead to > bad UX. > * Allow other clients to use this interface too, and use another protocol to > manage authorizations. Basically the idea would be not to expose this > interface, and require the client to request access to this privileged > interface through an authorizer protocol. Someone already mentioned it, this > is Orbital's approach [2]. This allows the compositor to spawn a dialog > asking > to the user "do you want to allow to create a virtual keyboard?". > > What do you think? > I'm in favor of option 3, which will be useful for other protocols as well, which are not necessarily in position to be kept in a permanent privileged process, e.g. screen recording. It would also make me happier as a protocol author, because the protocol becomes more compact and easier to maintain without explicit managing. > An event on the keyboard to signal when the keyboard is no longer active > (ie. when the compositor decides to destroy it) might still be useful, maybe. > After chatting out of band (thanks Simon for the clarification!), we painted an image where the compositor doesn't want the keyboard to exist any more, e.g. because the user revoked permission, or because it was turned off by the user. If it was only about permissions, it would seem like a good idea for the authorization protocol to handle disabling the virtual keyboard. Unfortunately, it seems to be only possible to render the global inert. That gets complicated because the global is a factory and its children need to be implicitly inert as well. There are
[PATCH v7 wayland-protocols] text-input: Add v3 of the text-input protocol
From: Carlos Garnacho This new protocol description is a simplification over v2. - All pre-edit text styling is gone. - Pre-edit cursor can span characters. - No events regarding input panel (OSK) state nor covered rectangle. Compositors are still free to handle situations where the keyboard focus rectangle is covered by the input panel. - No set_preferred_language request for clients. - There is no event to send keysyms. Compositors can use wl_keyboard interface instead. - All state is double-buffered, with specified state. Signed-off-by: Dorota Czaplejewicz Signed-off-by: Carlos Garnacho --- This change introduces whitespace and typo fixes. Cheers, Dorota Makefile.am| 1 + unstable/text-input/text-input-unstable-v3.xml | 374 + 2 files changed, 375 insertions(+) create mode 100644 unstable/text-input/text-input-unstable-v3.xml diff --git a/Makefile.am b/Makefile.am index 4b9a901..86d7ca9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3,6 +3,7 @@ unstable_protocols = \ unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml \ unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml \ unstable/text-input/text-input-unstable-v1.xml \ + unstable/text-input/text-input-unstable-v3.xml \ unstable/input-method/input-method-unstable-v1.xml \ unstable/xdg-shell/xdg-shell-unstable-v5.xml \ unstable/xdg-shell/xdg-shell-unstable-v6.xml \ diff --git a/unstable/text-input/text-input-unstable-v3.xml b/unstable/text-input/text-input-unstable-v3.xml new file mode 100644 index 000..64824ea --- /dev/null +++ b/unstable/text-input/text-input-unstable-v3.xml @@ -0,0 +1,374 @@ + + + + +Copyright © 2012, 2013 Intel Corporation +Copyright © 2015, 2016 Jan Arne Petersen +Copyright © 2017, 2018 Red Hat, Inc. +Copyright © 2018 Purism SPC + +Permission to use, copy, modify, distribute, and sell this +software and its documentation for any purpose is hereby granted +without fee, provided that the above copyright notice appear in +all copies and that both that copyright notice and this permission +notice appear in supporting documentation, and that the name of +the copyright holders not be used in advertising or publicity +pertaining to distribution of the software without specific, +written prior permission. The copyright holders make no +representations about the suitability of this software for any +purpose. It is provided "as is" without express or implied +warranty. + +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF +THIS SOFTWARE. + + + + + The zwp_text_input_v3 interface represents text input and input methods + associated with a seat. It provides enter/leave events to follow the + text input focus for a seat. + + Requests are used to enable/disable the text-input object and set + state information like surrounding and selected text or the content type. + The information about the entered text is sent to the text-input object + via the preedit_string and commit_string events. + + Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices + must not point to middle bytes inside a code point: they must either + point to the first byte of a code point or to the end of the buffer. + Lengths must be measured between two valid indices. + + Focus moving throughout surfaces will result in the emission of + zwp_text_input_v3.enter and zwp_text_input_v3.leave events. The focused + surface must perform zwp_text_input_v3.enable and + zwp_text_input_v3.disable requests as the keyboard focus moves across + editable and non-editable elements of the UI. Those two requests are not + expected to be paired with each other, the compositor must be able to + handle consecutive series of the same request. + + State is sent by the state requests (set_surrounding_text, + set_content_type and set_cursor_rectangle) and a commit request. After an + enter event or disable request all state information is invalidated and + needs to be resent by the client. + + This protocol defines requests and events necessary for regular clients + to communicate with an input
Re: [PATCH wayland-protocols] unstable: add xdg-primary-selection protocol
Hi Jonas, Any thoughts about this? Thanks, Simon On July 15, 2018 7:36 PM, Simon Ser wrote: > Hi Jonas, > > What do you think of this proposal? (It's basically the GTK protocol with > some prefix changes) > > Thanks, > > Simon > > On July 8, 2018 8:14 PM, Simon Ser wrote: > > This primary selection is similar in spirit to the eponymous > > in X11, allowing a quick "select text + middle click" shortcut > > to copying and pasting. > > > > It's otherwise very similar to its Wayland counterpart, and > > explicitly made consistent with it. > > > > Signed-off-by: Simon Ser > > --- > > This is a continuation of [1]. This protocol was pretty close to being > > accepted. > > > > I've chosen to put the xdg prefix because this primary selection is mostly > > relevant > > to desktop compositors. > > > > I've added myself as maintainer, Carlos and Lyude let me know if you want > > to replace > > me or be added to the list too. > > > > [1]: > > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027101.html > > > > Makefile.am | 3 +- > > unstable/xdg-primary-selection/README | 4 + > > .../xdg-primary-selection-unstable-v1.xml | 225 ++ > > 3 files changed, 231 insertions(+), 1 deletion(-) > > create mode 100644 unstable/xdg-primary-selection/README > > create mode 100644 > > unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 2b59d34..66a65af 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -19,7 +19,8 @@ unstable_protocols = > > \ > > > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml > > \ > > unstable/xdg-output/xdg-output-unstable-v1.xml > > \ > > unstable/input-timestamps/input-timestamps-unstable-v1.xml \ > > - unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ > > + unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > \ > > $(NULL) > > > > stable_protocols = > > \ > > diff --git a/unstable/xdg-primary-selection/README > > b/unstable/xdg-primary-selection/README > > new file mode 100644 > > index 000..ae0a402 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/README > > @@ -0,0 +1,4 @@ > > +Primary selection protocol > > + > > +Maintainers: > > +Simon Ser > > diff --git > > a/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > new file mode 100644 > > index 000..eb97425 > > --- /dev/null > > +++ b/unstable/xdg-primary-selection/xdg-primary-selection-unstable-v1.xml > > @@ -0,0 +1,225 @@ > > + > > + > > + > > +Copyright © 2015, 2016 Red Hat > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software and associated documentation files (the > > "Software"), > > +to deal in the Software without restriction, including without > > limitation > > +the rights to use, copy, modify, merge, publish, distribute, > > sublicense, > > +and/or sell copies of the Software, and to permit persons to whom the > > +Software is furnished to do so, subject to the following conditions: > > + > > +The above copyright notice and this permission notice (including the > > next > > +paragraph) shall be included in all copies or substantial portions of > > the > > +Software. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > > EXPRESS OR > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > > MERCHANTABILITY, > > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT > > SHALL > > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > > OTHER > > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > > +DEALINGS IN THE SOFTWARE. > > + > > + > > + > > +This protocol provides the ability to have a primary selection device > > to > > +match that of the X server. This primary selection is a shortcut to the > > +common clipboard selection, where text just needs to be selected in > > order > > +to allow copying it elsewhere. The de facto way to perform this action > > +is the middle mouse button, although it is not limited to this one. > > + > > +Clients wishing to honor primary selection should create a primary > > +selection source and set it as the selection through > > +xdg_primary_selection_device.set_selection whenever the text selection > > +changes. In order to minimize calls in pointer-driven text selection, > > +it should
Re: [PATCH] protocol: allow to send a zero physical output size
On Tue, Jul 24, 2018 at 11:44:35AM +0200, Olivier Fourdan wrote: > Hi, > > On Tue, 24 Jul 2018 at 11:34, Simon Ser wrote: > > > > On July 13, 2018 12:00 PM, Daniel Stone wrote: > > > Hi, > > > > > > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote: > > > > Physical size doesn't always make sense for all outputs. In case > > > > it's not available or not relevant, allow compositors to send zero. > > > > --- > > > > In practice this doesn't seem to break any client toolkit. We've been > > > > doing that for a long time in wlroots. > > > > > > Seems legitimate to me. I'd like to hear if anyone else touching > > > output has thoughts, but this is: > > > Acked-by: Daniel Stone > > > > Hi, > > > > Thanks for the ack. Olivier, Jonas, do you have opinions about this? > > FWIW, this is what Xrandr does, it makes sense to me as well, at least > from an Xwayland point of view :) Makes sense to me too, so this is Acked-by: Jonas Ådahl as well. Jonas > > Cheers, > Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: allow to send a zero physical output size
Hi, On Tue, 24 Jul 2018 at 11:34, Simon Ser wrote: > > On July 13, 2018 12:00 PM, Daniel Stone wrote: > > Hi, > > > > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote: > > > Physical size doesn't always make sense for all outputs. In case > > > it's not available or not relevant, allow compositors to send zero. > > > --- > > > In practice this doesn't seem to break any client toolkit. We've been > > > doing that for a long time in wlroots. > > > > Seems legitimate to me. I'd like to hear if anyone else touching > > output has thoughts, but this is: > > Acked-by: Daniel Stone > > Hi, > > Thanks for the ack. Olivier, Jonas, do you have opinions about this? FWIW, this is what Xrandr does, it makes sense to me as well, at least from an Xwayland point of view :) Cheers, Olivier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] protocol: allow to send a zero physical output size
On July 13, 2018 12:00 PM, Daniel Stone wrote: > Hi, > > On Tue, 3 Jul 2018 at 12:27, Simon Ser wrote: > > Physical size doesn't always make sense for all outputs. In case > > it's not available or not relevant, allow compositors to send zero. > > --- > > In practice this doesn't seem to break any client toolkit. We've been > > doing that for a long time in wlroots. > > Seems legitimate to me. I'd like to hear if anyone else touching > output has thoughts, but this is: > Acked-by: Daniel Stone Hi, Thanks for the ack. Olivier, Jonas, do you have opinions about this? Thanks, > Cheers, > Daniel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH v3 weston 4/5] tests: add test for setting gamma
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: Saturday, July 21, 2018 5:52 PM
> To: Harsha Manjula Mallikarjun (RBEI/ECF3)
>
> Cc: wayland
> Subject: Re: [PATCH v3 weston 4/5] tests: add test for setting gamma
>
> Hi Harsha,
>
> On Thu, 28 Jun 2018 at 14:28,
> wrote:
> > +static int
> > +gamma_update_event(void *data)
> > +{
> > + struct gamma_tobject *obj;
> > + struct output_obj *op_obj;
> > + uint16_t *r, *g, *b;
> > + bool all_tests_complete = true;
> > +
> > + obj = (struct gamma_tobject *)data;
> > +
> > + wl_list_for_each(op_obj, >output_list, link) {
> > + /*compute Gamma lookup table*/
> > + if (!op_obj->test_complete) {
>
> As a small style point, please make this 'if (op_obj->test_complete)
> [newline] continue;'. This removes one level of indentation from the
> branch.
>
> > + op_obj->gamma += 0.3;
> > + if (op_obj->gamma > 2.1) {
> > + op_obj->test_complete = true;
> > + /*End the test with gamma set to 1*/
> > + op_obj->gamma = 1.0;
> > + }
> > + r = malloc(sizeof(uint16_t) *
> > op_obj->output->gamma_size *
> 3);
> > + g = [op_obj->output->gamma_size];
> > + b = [op_obj->output->gamma_size];
> > +
> > + compute_gamma_lut(op_obj->gamma, op_obj->output-
> >gamma_size,
> > + r, g, b);
> > +
> > + op_obj->output->set_gamma(op_obj->output, op_obj-
> >output->gamma_size,
> > + r, g, b);
> > +
> > + free(r);
> > + all_tests_complete=false;
> > + }
> > + }
>
> So, I understand this would be a manual test where the user would
> visually verify that the gamma is changing in the way they would
> expect? I have no problem with that, but it would be nice to see this
> documented with an example as to what the user should be seeing with
> each step.
An application showing gamma value on screen along with the image would
be very nice I thought. Due to lack of time I did this simple plugin which
just changes Gamma/CTM irrespective of any application that is running. User
has to run an app manually though.
I can document with comments in code what is expected on display, with
each step increment in CTM and gamma values. Would this be fine?
>
> Also, lastly, is there a public libweston user for this new API?
There is a plan to use this from wayland-ivi-extension. Then a demo
app will also come along :-).
> It would be nice to have this be configurable.
I did not get this point. Do you mean that the inclusion of this test would be
configurable during build time? OR this feature of Gamma and CTM itself needs
to included based on configuration?
>
> Cheers,
> Daniel
Best Regards,
Harsha
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH v3 weston 3/5] compositor-drm: add support for CTM property
> -Original Message-
> From: Daniel Stone [mailto:dan...@fooishbar.org]
> Sent: Saturday, July 21, 2018 5:48 PM
> To: Harsha Manjula Mallikarjun (RBEI/ECF3)
>
> Cc: wayland
> Subject: Re: [PATCH v3 weston 3/5] compositor-drm: add support for CTM
> property
>
> Hi Harsha,
>
> On Thu, 28 Jun 2018 at 14:29,
> wrote:
> > + struct drm_output *output = to_drm_output(output_base);
> > + struct drm_backend *backend = to_drm_backend(output-
> >base.compositor);
> > + struct drm_color_ctm ctm;
> > + uint32_t ctm_blobid = 0;
> > + uint32_t ctm_prop_id;
> > + int row;
> > + int col;
> > + int rc;
> > + float coefficient;
> > +
> > + ctm_prop_id = output->props_crtc[WDRM_CRTC_CTM].prop_id;
> > + if (!ctm_prop_id)
> > + return;
> > +
> > + for (row = 0; row < 3; row++) {
> > + for (col = 0; col < 3; col++) {
> > + coefficient = ctm_matrix->d[(row * 4) + col];
> > + ctm.matrix[(row * 3) + col] =
> > +
> > drm_convert_to_ctm_format(coefficient);
> > + }
> > + }
> > +
> > + rc = drmModeCreatePropertyBlob(backend->drm.fd, ,
> sizeof(ctm),
> > + _blobid);
> > + if (!rc) {
> > + rc = drmModeObjectSetProperty(backend->drm.fd, output-
> >crtc_id,
> > + DRM_MODE_OBJECT_CRTC,
> > ctm_prop_id,
> > + ctm_blobid);
> > + if (rc)
> > + weston_log("failed to set ctm for crtc %d: %m\n",
> > + output->crtc_id);
> > +
> > + drmModeDestroyPropertyBlob(backend->drm.fd, ctm_blobid);
> > + }
> > +}
>
> Rather than having this directly applied in the function, I would like
> to see this moved to where drm_output_state is applied to an output.
> For atomic, this means that it's just another property set with all
> the others, making the code a little shorter. Doing the same for gamma
> as well would mean that the atomic path gets much shorter, and also
> that gamma and CTM updates are synchronised with each other - plus the
> pre-CTM degamma LUT if people want to use that, which would be a
> pretty trivial addition to the code.
>
> I'm not sure there's much point in supporting CTM on pre-atomic
> drivers: I don't know of any drivers which support CTM but not atomic.
>
> In order to do this, you would need to figure out when the gamma/CTM
> have changed relative to the current output configuration, and only
> apply it then. Maybe you could do this by checking the blob ID?
Thanks for the feedback. Yes, we can do this. I will figure out and provide
the next version of patches, mostly next week.
>
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC libinput] dox: switch to sphinx for the user-visible documentation
Hey, On Tue, 24 Jul 2018 at 06:43, Peter Hutterer wrote: > Sending this out as patch even though what really matters is the > output. Which is... here, tadaaa! > > https://people.freedesktop.org/~whot/libinput-rtd/ > > Basically the motivation here is to make the user-visible documentation less > awful, especially because these days, 90% of the doc needs are by end users, > not the developers. The API itself is just fine in doxygen, but for prose > doxygen's "Related Pages" features is not perfect. > > So I'm wondering if using RTD-style documentation is a better option here. > This patch is a more-or-less 1:1 conversion of the hand-written > documentation to use sphinx with the RTD theme. For a good chuckle, look at > the awk/sed script. (that script would go away anway after the one-time > conversion to an .rst source format). Makes sense, and this does look really good, but ... did you remember to run the script? The output at the URL above is full of @ref, @dot, etc. The rest looks good though. :) I'm all for something like Sphinx - not because I've ever used it or know any of its pros and cons, but it seems like a more stable tooling which is also more widely used. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Implementing right click and middle click drag
On Fri, Jul 20, 2018 at 11:10:32AM +0530, Sagar Tewari wrote: > On Wed, Jul 18, 2018 at 1:52 PM Peter Hutterer > wrote: > > > > > I'm not sure about the WITH_LOCK and POTENTIAL_UNLOCK parts, they should be > > (in theory) the same as the existing ones where DRAGGING_WAIT goes back to > > DRAGGING or DRAGGING_OR_TAP. Can you double-check this please whether it > > would work out? > > > > I've modified the state diagram so that the logic and nomenclature are > equivalent to the already present left tap drag logic. thanks! so, let's see: TOUCH_2_DRAGGING_2: third finger down needs to go to a DEAD state like the one at the bottom of the graph (so we recover accordingly until all fingers are up) TOUCH_2_DRAGGING_OR_TAP: that state is there twice now, was that intended? TOUCH_2_DRAGGING_OR_TAP (lower one): palm/thumb needs to go back to TOUCH_2_TAPPED (after marking that touch dead), otherwise an accidental palm brush resets the dragging state. TOUCH_2_DRAGGING_OR_TAP (upper left one): the dragging timeout needs to connect to TOUCH_2_DRAGGING TOUCH_2_DRAGGING_WAIT: needs a timeout to go to btn 2 release and then IDLE. I'm not sure the two TOUCH_2_DRAGGING_OR_TAP states can be combined into one, the thumb/palm handling may be different. But right now my brain is too fried already to figure that out, sorry. The rest is correct though, afaict. > > Right now, there's a dead end in it: > > TOUCH_2_DRAGGING -> finger up -> draglock enabled -> WITH_LOCK -> finger > > down -> POTENTIAL_UNLOCK > > > > If the finger is now labelled as palm or thumb, you're stuck in > > DRAGGING_WITH_LOCK until the next finger is down, never releasing. > > This seems to be intended (your point 2.) but we definitely need a timeout > > here. Imagine doing this, waiting 10 sec and then still continuing with the > > dragging on the next touch - not what the user would expect. > > > > so DRAGGING_WITH_LOCK needs a timeout to go to the button 2 release. > > I think I'd prefer "TOUCH_2_DRAGGING_WAIT" over TOUCH_2_DRAGGING_WITH_LOCK > > then to make it more consistent to the 1fg case. > > > > And TOUCH_2_DRAGGING_DOWN for no other reason than it's more expressive of > > the state and closer to the MULTITAP_DOWN naming scheme. > > > > > > oh, found another one: in POTENTIAL_UNLOCK you may get a second finger down > > - what do we do then? Either we go all the way back to TOUCH_2 which gives > > us the ability to right-click-drag and right-click. Or we go to some new > > state and resolve the 2fg tap as "end the draglock" tap. I really don't > > know > > which one is the more obvious one here. > > > > This has the potential to interfere with 2fg scrolling too: > > - draglog is enabled > > - 2 fingers down and up > > - 1 finger down, dragging > > - 1 finger up > > - 2 fingers down and dragging (2fg scrol > > > > l) > > > > > > > In synaptics driver it's possible to scroll by putting down a second > finger while dragging with a tap, it's super useful for selecting large > texts on webpages and in tools like blender. Would it be possible for > libinput to behave similarly? It looks like this too would require > duplicating the code and states for left, right and middle clicks. fwiw, this working in synaptics may be more by accident than intention. It may be possible in libinput but scrolling and tapping have different states, combining them intentionally is going to be tricky. right now, any time scrolling would kick in, synaptics is already in a 'dead' state and doesn't send any more events. With your state diagram, you'd end up in TOUCH_2_DRAGGING_2, so a two-finger scroll that triggers then won't affect the tapping state - hence it *should* work. > As a side note, would it be possible to make the state machine more > abstract, so that the similar behaviors for all the mouse buttons could be > handled with the same code? Maybe it won't be worth it, since the state > machine is a relatively short part of the libinput source. I'm going to say it's not worth it - as soon as you introduce conditions for the various paths you might as well throw the state machine out because it's too hard to analyze. Right now, the state machine is a mess but it defines exactly what happens when you transition from a->b->c. This is incredibly useful when trying to figure out why a bug triggers. Making it more abstract means sacrificing coding speed for debugging time - not a good trade-off IMO (especially since I'll be then one debugging ;) Cheers, Peter > Right now, this would... uhm, land us in TOUCH_2_DRAGGING, so it'd be a 2fg > > scroll with the right button held down. And (hopefully) a warning in the > > code about an invalid state ;) > > > > Oh, and once you handle the second finger down in POTENTIAL_UNLOCK you now > > have to resolve a third finger down in whatever state comes next. Good > > luck :) > > > Best Regards > Sagar Tewari ___ wayland-devel mailing list
