Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Daniel Vetter]

On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov  wrote:
> On 13 April 2018 at 11:00, Daniel Vetter  wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not revoke commit rights for people no longer
>> regularly active in a given project, as long as they're still part of
>> the larger community.
>>
>> Finally make sure that commit rights, like anything happening on fd.o
>> infrastructre, is subject to the fd.o's Code of Conduct.
>>
>> v2: Point at MAINTAINERS for contact info (Daniel S.)
>>
>> v3:
>> - Make it clear that commit rights are voluntary and that committers
>>   need to acknowledge positively when they're nominated by someone
>>   else (Keith).
>> - Encourage committers to drop their commit rights when they're no
>>   longer active, and make it clear they'll get readded (Keith).
>> - Add a line that maintainers and committers should actively nominate
>>   new committers (me).
>>
>> v4: Typo (Petri).
>>
>> v5: Typo (Sean).
>>
>> v6: Wording clarifications and spelling (Jani).
>>
>> v7: Require an explicit commitment to the documented merge criteria
>> and rules, instead of just the implied one through the Code of Conduct
>> threat (Jani).
>>
>> Acked-by: Alex Deucher 
>> Acked-by: Arkadiusz Hiler 
>> Acked-by: Daniel Stone 
>> Acked-by: Eric Anholt 
>> Acked-by: Gustavo Padovan 
>> Acked-by: Petri Latvala 
>> Cc: Alex Deucher 
>> Cc: Arkadiusz Hiler 
>> Cc: Ben Widawsky 
>> Cc: Daniel Stone 
>> Cc: Dave Airlie 
>> Cc: Eric Anholt 
>> Cc: Gustavo Padovan 
>> Cc: Jani Nikula 
>> Cc: Joonas Lahtinen 
>> Cc: Keith Packard 
>> Cc: Kenneth Graunke 
>> Cc: Kristian H. Kristensen 
>> Cc: Maarten Lankhorst 
>> Cc: Petri Latvala 
>> Cc: Rodrigo Vivi 
>> Cc: Sean Paul 
>> Reviewed-by: Keith Packard 
>> Signed-off-by: Daniel Vetter 
>> ---
>> If you wonder about the wide distribution list for an igt patch: I'd
>> like to start a discussions about x.org community norms around commit
>> rights at large, at least for all the shared repos. I plan to propose
>> the same text for drm-misc and libdrm too, and hopefully others like
>> mesa/xserver/wayland would follow.
>>
> I think the idea is pretty good, simply highlighting some bits.
>
> What you've outlined in this patch has been in practise for many years:
>  a) undocumented, applicable to most xorg projects [1]
>  b) documented, mesa

Hm, I chatted with a few mesa devs about this, and I wasn't aware
there's explicit documentation for mesa. Where is it? I'd very much
want to align as much as we can.

> IMHO having this explicitly documented and others
> (wayland/weston/wayland-protocols and xserver repos) following suite
> is a big plus.

Yeah, that's the idea. Hence plenty of Cc: for this igt patch.
-Daniel

>
> HTH
> Emil
>
> [1] As in all of https://cgit.freedesktop.org/xorg but xserver



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

[Emil Velikov]

On 13 April 2018 at 11:00, Daniel Vetter  wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in a given project, as long as they're still part of
> the larger community.
>
> Finally make sure that commit rights, like anything happening on fd.o
> infrastructre, is subject to the fd.o's Code of Conduct.
>
> v2: Point at MAINTAINERS for contact info (Daniel S.)
>
> v3:
> - Make it clear that commit rights are voluntary and that committers
>   need to acknowledge positively when they're nominated by someone
>   else (Keith).
> - Encourage committers to drop their commit rights when they're no
>   longer active, and make it clear they'll get readded (Keith).
> - Add a line that maintainers and committers should actively nominate
>   new committers (me).
>
> v4: Typo (Petri).
>
> v5: Typo (Sean).
>
> v6: Wording clarifications and spelling (Jani).
>
> v7: Require an explicit commitment to the documented merge criteria
> and rules, instead of just the implied one through the Code of Conduct
> threat (Jani).
>
> Acked-by: Alex Deucher 
> Acked-by: Arkadiusz Hiler 
> Acked-by: Daniel Stone 
> Acked-by: Eric Anholt 
> Acked-by: Gustavo Padovan 
> Acked-by: Petri Latvala 
> Cc: Alex Deucher 
> Cc: Arkadiusz Hiler 
> Cc: Ben Widawsky 
> Cc: Daniel Stone 
> Cc: Dave Airlie 
> Cc: Eric Anholt 
> Cc: Gustavo Padovan 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Keith Packard 
> Cc: Kenneth Graunke 
> Cc: Kristian H. Kristensen 
> Cc: Maarten Lankhorst 
> Cc: Petri Latvala 
> Cc: Rodrigo Vivi 
> Cc: Sean Paul 
> Reviewed-by: Keith Packard 
> Signed-off-by: Daniel Vetter 
> ---
> If you wonder about the wide distribution list for an igt patch: I'd
> like to start a discussions about x.org community norms around commit
> rights at large, at least for all the shared repos. I plan to propose
> the same text for drm-misc and libdrm too, and hopefully others like
> mesa/xserver/wayland would follow.
>
I think the idea is pretty good, simply highlighting some bits.

What you've outlined in this patch has been in practise for many years:
 a) undocumented, applicable to most xorg projects [1]
 b) documented, mesa

IMHO having this explicitly documented and others
(wayland/weston/wayland-protocols and xserver repos) following suite
is a big plus.

HTH
Emil

[1] As in all of https://cgit.freedesktop.org/xorg but xserver
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 0/1] Initialization race against udev

[Matt Hoosier]

On Sun, Apr 22, 2018 at 11:01 PM, Peter Hutterer 
wrote:

> On Sun, Apr 22, 2018 at 06:07:36PM +, Friedrich, Eugen (ADITG/ESB)
> wrote:
> > Hi, sorry for late replay
> >
> > Best regards
> >
> > Eugen Friedrich
> > Engineering Software Base (ADITG/ESB)
> >
> > Tel. +49 5121 49 6921
> > > -Original Message-
> > > From: Peter Hutterer [mailto:peter.hutte...@who-t.net]
> > > Sent: Freitag, 6. April 2018 04:29
> > > To: Friedrich, Eugen (ADITG/ESB)
> > > Cc: Matt Hoosier; Pekka Paalanen; wayland mailing list
> > > Subject: Re: [PATCH libinput 0/1] Initialization race against udev
> > >
> > > On Thu, Apr 05, 2018 at 01:20:51PM +, Friedrich, Eugen (ADITG/ESB)
> wrote:
> > > > Hi Peter
> > > >
> > > > Best regards
> > > >
> > > > Eugen Friedrich
> > > > Engineering Software Base (ADITG/ESB)
> > > >
> > > > Tel. +49 5121 49 6921
> > > >
> > > > > -Original Message-
> > > > > From: wayland-devel [mailto:wayland-devel-
> > > > > boun...@lists.freedesktop.org] On Behalf Of Peter Hutterer
> > > > > Sent: Donnerstag, 5. April 2018 06:27
> > > > > To: Matt Hoosier
> > > > > Cc: Pekka Paalanen; wayland mailing list
> > > > > Subject: Re: [PATCH libinput 0/1] Initialization race against udev
> > > > >
> > > > > On Wed, Apr 04, 2018 at 09:04:32AM -0500, Matt Hoosier wrote:
> > > > > > I encounter another "bad" behavior related to multiple firings
> of the UDev
> > > > > > 'add' event for a given input node.
> > > > > >
> > > > > > Typically on modest embedded systems, you do not want to run the
> > > > > exhaustive
> > > > > > 'udevadm trigger' during the main booting sequence. That causes
> hundreds
> > > > > or
> > > > > > thousands of UDev nodes to be crawled and processed by udevd all
> during
> > > > > the
> > > > > > first moments of userspace. These overall bulk of these nodes
> are pretty
> > > > > > much irrelevant to the use-case of the device. The time spent
> processing
> > > > > > these non-essential /sys devices can easily slow down the
> device's
> > > > > progress
> > > > > > toward starting a UI with basic touch support and loading
> drivers for the
> > > > > > handful of essential peripherals by 10 or 15 seconds.
> > > > > >
> > > > > > Instead, it works better to manually command the same UDev
> coldplugging
> > > > > > that would have been done by 'udevadm trigger', but for a very
> small
> > > > > > hand-picked set of devices rather than everything in
> /sys/devices. The time
> > > > > > savings are large. Of course, for completeness you do eventually
> have to
> > > > > > run 'udevadm trigger' so that the full set of hardware and
> kernel software
> > > > > > features are activated, but that can wait until after the main
> KPIs are
> > > > > > achieved.
> > > > > >
> > > > > > This scheme generally works just fine. Manually stimulating
> udevd to
> > > > > > coldplug the specific devices you need keeps everything general:
> > > > > > applications that find their hardware with UDev (such as with
> libinput or
> > > > > > Weston's DRM backend) all get to rely on their usual well-tested
> > > > > codepaths.
> > > > > >
> > > > > > But there is a snag: if a device like /dev/input/event0 has been
> > > > > > coldplugged once with the hands-on technique, then all the
> daemons that
> > > > > > care about it have already seen one UDev ACTION=add event for
> it. When
> > > > > the
> > > > > > late-running 'udevadm trigger' does its exhaustive sweep across
> > > > > > /sys/devices, this will cause a second ACTION=add event to be
> triggered
> > > > > for
> > > > > > /dev/input/event0. Currently (well, with libinput 1.1.1) this
> causes
> > > > > > libinput -- and consequently Weston -- to open a second
> filedescriptor
> > > > > > against /dev/input/event0, so that all input events are received
> in
> > > > > > duplicate. That confuses the compositor's and applications'
> input event
> > > > > > handling.
> > > > > >
> > > > > > Would it be tolerable to put a patch into either libinput or
> Weston to
> > > > > > guard against double-opening the same input device? I realize
> that the
> > > > > > scheme outlined above is probably technically in violation of
> the expected
> > > > > > UDev initialization scheme, but I'm not aware of any way to
> suppress
> > > > > udevd
> > > > > > from broadcasting the 'add' action to all udev clients even
> though the
> > > > > > device has already been coldplugged once. It seems to me at
> least plausible
> > > > > > that the Weston stack would benefit from guarding against
> getting into this
> > > > > > bad state from receiving unexpected UDev events.
> > > > >
> > > > >
> > > > > I don't think a weston patch is likely to help you here since
> libinput's
> > > > > udev handling is independent of weston. but tbh, I'd rather not do
> this in
> > > > > libinput either. as you write, you're not really behaving like
> udev is
> > > > > supposed to and once we start having to deal with that the
> floodgates are
> > > > > open for 

Re: [PATCH weston 21/25] protocol: add weston_touch_calibration

[Pekka Paalanen]

On Wed, 18 Apr 2018 11:30:42 +0300
Pekka Paalanen  wrote:

> On Mon, 16 Apr 2018 13:40:44 +1000
> Peter Hutterer  wrote:
> 
> > On Fri, Apr 13, 2018 at 10:51:37AM +0300, Pekka Paalanen wrote:  
> > >   
> > > Well, it does touch-downs at least. I think if motion event would end
> > > up out of range, I'll send cancel event followed by invalid touch.
> > > Whee, I found use for the cancel event!
> > 
> > The cancel event would also be used for the multitouch-case, right?
> > If a second touch appears before the first one is fully processed, you also
> > need to cancel the first touch. Doesn't even need to be intentional by the
> > user, could be a palm touch or an accidental touch where they're holding the
> > screen on an edge.  
> 
> I hadn't even thought of that, sounds good.

Actually, I don't have to filter multiple touchpoints in the server.
The protocol is copied from the wl_touch interface and can handle
multiple touch points just fine. It can be up to the client to enter a
denial mode on a second touch down until they are all up.

Likewise, if the user puts first touch down on a right device, and a
second touch down on a wrong device which results in a invalid_touch
event, it can be up to the client to decide whether it accepts the
first touch or not.

I'll just have to make the client deal with those.

Do you see any problem with this?


Thanks,
pq


pgpbJr8kmJ6PH.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCHv6 wayland-protocols] Add name event to xdg-output

[Drew DeVault]

Signed-off-by: Drew DeVault 
Reviewed-by: Simon Ser 
Reviewed-by: Jonas Ådahl 
---
Only change is the additional 

 .../xdg-output/xdg-output-unstable-v1.xml | 47 ++-
 1 file changed, 45 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
b/unstable/xdg-output/xdg-output-unstable-v1.xml
index 0c0c481..6eed8b0 100644
--- a/unstable/xdg-output/xdg-output-unstable-v1.xml
+++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
@@ -54,7 +54,7 @@
 reset.
   
 
-  
+  
 
   A global factory interface for xdg_output objects.
 
@@ -77,7 +77,7 @@
 
   
 
-  
+  
 
   An xdg_output describes part of the compositor geometry.
 
@@ -157,5 +157,48 @@
   
 
 
+
+
+  
+Many compositors will assign names to their outputs, show them to the user,
+allow them to be configured by name, etc. The client may wish to know this
+name as well to offer the user similar behaviors.
+
+The naming convention is compositor defined, but limited to alphanumeric
+characters and dashes (-). Each name is unique among all wl_output
+globals, but if a wl_output global is destroyed the same name may be reused
+later. The names will also remain consistent across sessions with the same
+hardware and software configuration.   

+
+Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do not
+assume that the name is a reflection of an underlying DRM connector, X11
+connection, etc.
+
+The name event is sent after creating an xdg_output (see
+xdg_output_manager.get_xdg_output). This event is only sent once per
+xdg_output, and the name does not change over the lifetime of the wl_output
+global.
+  
+  
+
+
+
+  
+Many compositors can produce human-readable descriptions of their outputs.
+The client may wish to know this description as well, to communicate the
+user for various purposes.
+
+The description is a UTF-8 string with no convention defined for its
+contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
+output via :1'.
+
+The description event is sent after creating an xdg_output (see
+xdg_output_manager.get_xdg_output). This event is only sent once per
+xdg_output, and the description does not change over the lifetime of the
+wl_output global. The description is optional, and may not be sent at all.
+  
+  
+
+
   
 
-- 
2.17.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv5 wayland-protocols] Add name event to xdg-output

[Jonas Ådahl]

On Mon, Apr 23, 2018 at 11:29:52AM +0200, Drew DeVault wrote:
> Signed-off-by: Drew DeVault 
> Reviewed-by: Simon Ser 

One nit inline I just spotted. With that fixed, this is

Reviewed-by: Jonas Ådahl 

I'll wait a bit to see if anyone has any input. If not, and no v6 is
sent, I can amend the above nit and land it within a few days.

> ---
> This revision adds an additional description field.
> 
>  .../xdg-output/xdg-output-unstable-v1.xml | 46 ++-
>  1 file changed, 44 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> index 0c0c481..fb230fc 100644
> --- a/unstable/xdg-output/xdg-output-unstable-v1.xml
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -54,7 +54,7 @@
>  reset.
>
>  
> -  
> +  
>  
>A global factory interface for xdg_output objects.
>  
> @@ -77,7 +77,7 @@
>  
>
>  
> -  
> +  
>  
>An xdg_output describes part of the compositor geometry.
>  
> @@ -157,5 +157,47 @@
>
>  

The convention is to have comment here saying:  to make it easier to spot what belongs to what version.


Jonas

>  
> +
> +  
> +Many compositors will assign names to their outputs, show them to the 
> user,
> +allow them to be configured by name, etc. The client may wish to know 
> this
> +name as well to offer the user similar behaviors.
> +
> +The naming convention is compositor defined, but limited to alphanumeric
> +characters and dashes (-). Each name is unique among all wl_output
> +globals, but if a wl_output global is destroyed the same name may be 
> reused
> +later. The names will also remain consistent across sessions with the 
> same
> +hardware and software configuration. 
>   
> +
> +Examples of names include 'HDMI-A-1', 'WL-1', 'X11-1', etc. However, do 
> not
> +assume that the name is a reflection of an underlying DRM connector, X11
> +connection, etc.
> +
> +The name event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output). This event is only sent once per
> +xdg_output, and the name does not change over the lifetime of the 
> wl_output
> +global.
> +  
> +  
> +
> +
> +
> +  
> +Many compositors can produce human-readable descriptions of their 
> outputs.
> +The client may wish to know this description as well, to communicate the
> +user for various purposes.
> +
> +The description is a UTF-8 string with no convention defined for its
> +contents. Examples might include 'Foocorp 11" Display' or 'Virtual X11
> +output via :1'.
> +
> +The description event is sent after creating an xdg_output (see
> +xdg_output_manager.get_xdg_output). This event is only sent once per
> +xdg_output, and the description does not change over the lifetime of the
> +wl_output global. The description is optional, and may not be sent at 
> all.
> +  
> +  
> +
> +
>
>  
> -- 
> 2.17.0
> 
> ___
> 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 0/2] Add tablet_v2 support to weston-info

[Pekka Paalanen]

On Tue, 24 Apr 2018 09:31:21 +0200
w...@ongy.net wrote:

> From: Markus Ongyerth 
> 
> Hi,
> 
> the first commit adds support for the tablet-unstable-v2 protocol to
> weston-info. It will output the currently attached tablets, tablet_pads and
> tablet_tools with all info provided by the protocol.
> An example output:
> 
> ```
> interface: 'zwp_tablet_manager_v2', version: 1, name: 11
>   tablet_seat: seat0
>   tablet: Wacom Intuos3 6x8 Pen
>   vendor: 1386
>   product: 177
>   path: 
> /sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/0003:056A:00B1.0019/input/input106/event5
>   pad:
>   buttons: 8
>   path: 
> /sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/0003:056A:00B1.0019/input/input108/event6
>   group:
>   modes: 1
>   strips: 2
>   rings: 0
>   buttons: 0 1 2 3 4 5 6 7
>   tablet_tool: pen
>   hardware serial: 7803f99
>   hardware wacom: 823
>   capabilities: tilt pressure distance
> ```
> 
> The second patch is a mostly unrelated patch that fixes a memory-leak in
> weston-info I found while searching for ones I introduced with valgrind
> 
> Cheers,
> ongy
> 
> Markus Ongyerth (2):
>   weston-info: Add support for tablet-unstable-v2
>   weston-info: destroy wl_keyboard
> 
>  Makefile.am   |  14 +-
>  clients/weston-info.c | 854 +-
>  2 files changed, 859 insertions(+), 9 deletions(-)
> 

Hi,

a nice idea, both patches are:
Acked-by: Pekka Paalanen 

I'll leave the detailed review for others.


Thanks,
pq


pgpWnOTYBAijp.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/4] RFC: Add Meson build

[Pekka Paalanen]

On Tue, 24 Apr 2018 09:03:05 +0100
Emmanuele Bassi  wrote:

> On 23 April 2018 at 15:06, Pekka Paalanen  wrote:
> 
> > >  - the Doxygen-generated man pages are installed under $datadir/man,
> > >instead of $mandir, because of Doxygen peculiarities, like forcing
> > >the creation of a `man3` directory for no reason; additionally, Meson
> > >doesn't really like it when custom targets start having
> > >sub-directories. The current system is the least terrible I could
> > >come up with, but the only way I figure it can be solved appropriately
> > >is to write a Doxygen module for Meson. Sadly, I don't have the time
> > >to work on it.  
> >
> > For a while I've been wondering if we should ditch doxygen and
> > everything we have and use, say, hotdoc[1] with the C extension[2] that
> > uses Clang to parse the code.
> >
> >  
> We use HotDoc at Endless for our SDK[0], and the results are definitely
> more pleasing to the eye than raw Doxygen — though I can't say if it works
> just as well when integrated with Meson. It definitely warrants exploration.
> 
> [0]: http://endlessm.github.io/eos-knowledge-lib/docs/master/
> 
> >  - no Publican support; I've asked on the #wayland IRC channel, and it  
> > >seems it's mostly a relic of the initial documentation effort; it's
> > >a lot easier to just dump the Doxygen-generated HTML, though it's
> > >probably worth spending some time making the CSS nicer, given the
> > >default Doxygen style being less than stellar.  
> >
> > Yeah, Publican was ripped out years ago, I would not expect it even
> > could run. Just the doc build system was left unsimplified AFAIU.
> >  
> 
> The Autotools build does build it and install it, but I just looked at the
> resulting installed tree, not really at its contents.

We do build and install(?) the docbook (or whatever format it is now)
that originally was written with Publican. You may see directory or
file names or directory structure related to Publican, but those are
really just leftovers.

By ripping out Publican I mean the use of that tool, not the
documentation, which we publish at
https://wayland.freedesktop.org/docs/html/

> > >  - I haven't thoroughly tested this build. I've diff'd the installed
> > >trees, and checked the exported symbols; I've also rebuilt GTK+ (both
> > >stable and development branches) on top of it, but it *definitely*
> > >needs some more testing.
> > >
> > > I wanted to drop this on the mailing list before I accidentaly leave it
> > > to rot on my repo.  
> >
> > I very much hope someone continues this effort.
> >
> >  
> I wanted to clarify this bit: I'd like to finish this work and get it
> merged; the Doxygen issue of not installing under the directory specified
> by `--mandir` is kind of the only blocker I see, especially if Publican's
> state means it can be skipped.

Well, there is no Publican. There is the "Wayland book" which we want
to keep on building and publishing. I don't think anyone cares about
how the build system builds it, as long as it builds it. The
'publish-doc' script might need updating also.

The mandir thing sounds problematic indeed.

> What I don't foresee having time to work on is either adding a Doxygen
> module for Meson, or porting the documentation to another system; I should
> be able to work with the Meson devs to get some fixes that would, at least,
> allow us to install the contents of the generated `man/man3` directory
> under `mandir`, though.

Very good, that is and perhaps exceeds a bit my expectations as well.

> Right now, I just wanted to get some review and feedback on the list of
> issues I've identified, and in case somebody wants to try this out, if
> there are other things I've missed.

I appreciate your effort very much.


Thanks,
pq


pgpBtFQV_0Te7.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 0/4] RFC: Add Meson build

[Emmanuele Bassi]

On 23 April 2018 at 15:06, Pekka Paalanen  wrote:

> >  - the Doxygen-generated man pages are installed under $datadir/man,
> >instead of $mandir, because of Doxygen peculiarities, like forcing
> >the creation of a `man3` directory for no reason; additionally, Meson
> >doesn't really like it when custom targets start having
> >sub-directories. The current system is the least terrible I could
> >come up with, but the only way I figure it can be solved appropriately
> >is to write a Doxygen module for Meson. Sadly, I don't have the time
> >to work on it.
>
> For a while I've been wondering if we should ditch doxygen and
> everything we have and use, say, hotdoc[1] with the C extension[2] that
> uses Clang to parse the code.
>
>
We use HotDoc at Endless for our SDK[0], and the results are definitely
more pleasing to the eye than raw Doxygen — though I can't say if it works
just as well when integrated with Meson. It definitely warrants exploration.

[0]: http://endlessm.github.io/eos-knowledge-lib/docs/master/

>  - no Publican support; I've asked on the #wayland IRC channel, and it
> >seems it's mostly a relic of the initial documentation effort; it's
> >a lot easier to just dump the Doxygen-generated HTML, though it's
> >probably worth spending some time making the CSS nicer, given the
> >default Doxygen style being less than stellar.
>
> Yeah, Publican was ripped out years ago, I would not expect it even
> could run. Just the doc build system was left unsimplified AFAIU.
>

The Autotools build does build it and install it, but I just looked at the
resulting installed tree, not really at its contents.


> >  - I haven't thoroughly tested this build. I've diff'd the installed
> >trees, and checked the exported symbols; I've also rebuilt GTK+ (both
> >stable and development branches) on top of it, but it *definitely*
> >needs some more testing.
> >
> > I wanted to drop this on the mailing list before I accidentaly leave it
> > to rot on my repo.
>
> I very much hope someone continues this effort.
>
>
I wanted to clarify this bit: I'd like to finish this work and get it
merged; the Doxygen issue of not installing under the directory specified
by `--mandir` is kind of the only blocker I see, especially if Publican's
state means it can be skipped.

What I don't foresee having time to work on is either adding a Doxygen
module for Meson, or porting the documentation to another system; I should
be able to work with the Meson devs to get some fixes that would, at least,
allow us to install the contents of the generated `man/man3` directory
under `mandir`, though.

Right now, I just wanted to get some review and feedback on the list of
issues I've identified, and in case somebody wants to try this out, if
there are other things I've missed.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 1/2] weston-info: Add support for tablet-unstable-v2

[Simon Ser]

On April 24, 2018 8:31 AM,  wrote:
> From: Markus Ongyerth 
> 
> This now prints each tablet seat with at least one tablet/pad/tool
> attached.
> For each tablet seat, each tablet, pad and tool is printed with as much
> detail about the device as the protocol provides.
> Seat info is stored to be referenced, because the protocol requires to
> request a tablet_seat for each wl_seat and it's not guaranteed that the
> tablet_v2_manager is available when seats are advertised.
> 
> Signed-off-by: Markus Ongyerth 

Overall LGTM.

> ---
>  Makefile.am   |  14 +-
>  clients/weston-info.c | 844 ++
>  2 files changed, 853 insertions(+), 5 deletions(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index 69ca6cba..ac0f5471 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -824,11 +824,13 @@ weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  weston_info_SOURCES =\
>   clients/weston-info.c   \
>   shared/helpers.h
> -nodist_weston_info_SOURCES = \
> - protocol/presentation-time-protocol.c   \
> - protocol/presentation-time-client-protocol.h\
> - protocol/linux-dmabuf-unstable-v1-protocol.c\
> - protocol/linux-dmabuf-unstable-v1-client-protocol.h
> +nodist_weston_info_SOURCES = \
> + protocol/presentation-time-protocol.c   \
> + protocol/presentation-time-client-protocol.h\
> + protocol/linux-dmabuf-unstable-v1-protocol.c\
> + protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c  \
> + protocol/tablet-unstable-v2-client-protocol.h
>  weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
>  weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
>  
> @@ -888,6 +890,8 @@ BUILT_SOURCES +=  \
>   protocol/ivi-application-client-protocol.h  \
>   protocol/linux-dmabuf-unstable-v1-protocol.c\
>   protocol/linux-dmabuf-unstable-v1-client-protocol.h \
> + protocol/tablet-unstable-v2-protocol.c  \
> + protocol/tablet-unstable-v2-client-protocol.h   \
>   protocol/input-timestamps-unstable-v1-protocol.c\
>   protocol/input-timestamps-unstable-v1-client-protocol.h
>  
> diff --git a/clients/weston-info.c b/clients/weston-info.c
> index 386bd412..7ae6f10b 100644
> --- a/clients/weston-info.c
> +++ b/clients/weston-info.c
> @@ -41,6 +41,7 @@
>  #include "shared/zalloc.h"
>  #include "presentation-time-client-protocol.h"
>  #include "linux-dmabuf-unstable-v1-client-protocol.h"
> +#include "tablet-unstable-v2-client-protocol.h"
>  
>  typedef void (*print_info_t)(void *info);
>  typedef void (*destroy_info_t)(void *info);
> @@ -113,6 +114,7 @@ struct linux_dmabuf_info {
>  
>  struct seat_info {
>   struct global_info global;
> + struct wl_list global_link;
>   struct wl_seat *seat;
>   struct weston_info *info;
>  
> @@ -123,6 +125,75 @@ struct seat_info {
>   int32_t repeat_delay;
>  };
>  
> +struct tablet_v2_path {
> + struct wl_list link;
> + char *path;
> +};

Maybe a wl_array should be used instead?

> +
> +struct tablet_tool_info {
> + struct wl_list link;
> + struct zwp_tablet_tool_v2 *tool;
> +
> + uint64_t hardware_serial;
> + uint64_t hardware_id_wacom;
> + enum zwp_tablet_tool_v2_type type;
> + 
> + int tilt;
> + int pressure;
> + int distance;
> + int rotation;
> + int slider;
> + int wheel;
> +};
> +
> +struct tablet_pad_group_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_group_v2 *group;
> +
> + uint32_t modes;
> + size_t button_count;
> + int *buttons;
> + size_t strips;
> + size_t rings;
> +};
> +
> +struct tablet_pad_info {
> + struct wl_list link;
> + struct zwp_tablet_pad_v2 *pad;
> +
> + uint32_t buttons;
> + struct wl_list paths;
> + struct wl_list groups;
> +};
> +
> +struct tablet_info {
> + struct wl_list link;
> + struct zwp_tablet_v2 *tablet;
> +
> + char *name;
> + uint32_t vid, pid;
> + struct wl_list paths;
> +};
> +
> +struct tablet_seat_info {
> + struct wl_list link;
> +
> + struct zwp_tablet_seat_v2 *seat;
> + struct seat_info *seat_info;
> +
> + struct wl_list tablets;
> + struct wl_list tools;
> + struct wl_list pads;
> +};
> +
> +struct tablet_v2_info {
> + struct global_info global;
> + struct zwp_tablet_manager_v2 *manager;
> + struct weston_info *info;
> +
> + struct wl_list seats;
> +};
> +
>  struct presentation_info {
>   struct global_info global;
>   struct wp_presentation *presentation;
> @@ -134,6 +205,9 @@ struct weston_info {
>   struct wl_display *display;
>   struct wl_registry 

[PATCH 2/2] weston-info: destroy wl_keyboard

[wl]

From: Markus Ongyerth 

Fixes a memory leak by calling wl_keyboard_destroy on a any keyboard
that was used to listen for events.

Signed-off-by: Markus Ongyerth 
---
 clients/weston-info.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/clients/weston-info.c b/clients/weston-info.c
index 7ae6f10b..95ada503 100644
--- a/clients/weston-info.c
+++ b/clients/weston-info.c
@@ -118,6 +118,7 @@ struct seat_info {
struct wl_seat *seat;
struct weston_info *info;
 
+   struct wl_keyboard *keyboard;
uint32_t capabilities;
char *name;
 
@@ -497,10 +498,8 @@ seat_handle_capabilities(void *data, struct wl_seat 
*wl_seat,
return;
 
if (caps & WL_SEAT_CAPABILITY_KEYBOARD) {
-   struct wl_keyboard *keyboard;
-
-   keyboard = wl_seat_get_keyboard(seat->seat);
-   wl_keyboard_add_listener(keyboard, _listener,
+   seat->keyboard = wl_seat_get_keyboard(seat->seat);
+   wl_keyboard_add_listener(seat->keyboard, _listener,
 seat);
 
seat->info->roundtrip_needed = true;
@@ -530,6 +529,9 @@ destroy_seat_info(void *data)
if (seat->name != NULL)
free(seat->name);
 
+   if (seat->keyboard)
+   wl_keyboard_destroy(seat->keyboard);
+
wl_list_remove(>global_link);
 }
 
-- 
2.17.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] weston-info: Add support for tablet-unstable-v2

[wl]

From: Markus Ongyerth 

This now prints each tablet seat with at least one tablet/pad/tool
attached.
For each tablet seat, each tablet, pad and tool is printed with as much
detail about the device as the protocol provides.
Seat info is stored to be referenced, because the protocol requires to
request a tablet_seat for each wl_seat and it's not guaranteed that the
tablet_v2_manager is available when seats are advertised.

Signed-off-by: Markus Ongyerth 
---
 Makefile.am   |  14 +-
 clients/weston-info.c | 844 ++
 2 files changed, 853 insertions(+), 5 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 69ca6cba..ac0f5471 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -824,11 +824,13 @@ weston_simple_im_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 weston_info_SOURCES =  \
clients/weston-info.c   \
shared/helpers.h
-nodist_weston_info_SOURCES =   \
-   protocol/presentation-time-protocol.c   \
-   protocol/presentation-time-client-protocol.h\
-   protocol/linux-dmabuf-unstable-v1-protocol.c\
-   protocol/linux-dmabuf-unstable-v1-client-protocol.h
+nodist_weston_info_SOURCES =   \
+   protocol/presentation-time-protocol.c   \
+   protocol/presentation-time-client-protocol.h\
+   protocol/linux-dmabuf-unstable-v1-protocol.c\
+   protocol/linux-dmabuf-unstable-v1-client-protocol.h \
+   protocol/tablet-unstable-v2-protocol.c  \
+   protocol/tablet-unstable-v2-client-protocol.h
 weston_info_LDADD = $(WESTON_INFO_LIBS) libshared.la
 weston_info_CFLAGS = $(AM_CFLAGS) $(CLIENT_CFLAGS)
 
@@ -888,6 +890,8 @@ BUILT_SOURCES +=\
protocol/ivi-application-client-protocol.h  \
protocol/linux-dmabuf-unstable-v1-protocol.c\
protocol/linux-dmabuf-unstable-v1-client-protocol.h \
+   protocol/tablet-unstable-v2-protocol.c  \
+   protocol/tablet-unstable-v2-client-protocol.h   \
protocol/input-timestamps-unstable-v1-protocol.c\
protocol/input-timestamps-unstable-v1-client-protocol.h
 
diff --git a/clients/weston-info.c b/clients/weston-info.c
index 386bd412..7ae6f10b 100644
--- a/clients/weston-info.c
+++ b/clients/weston-info.c
@@ -41,6 +41,7 @@
 #include "shared/zalloc.h"
 #include "presentation-time-client-protocol.h"
 #include "linux-dmabuf-unstable-v1-client-protocol.h"
+#include "tablet-unstable-v2-client-protocol.h"
 
 typedef void (*print_info_t)(void *info);
 typedef void (*destroy_info_t)(void *info);
@@ -113,6 +114,7 @@ struct linux_dmabuf_info {
 
 struct seat_info {
struct global_info global;
+   struct wl_list global_link;
struct wl_seat *seat;
struct weston_info *info;
 
@@ -123,6 +125,75 @@ struct seat_info {
int32_t repeat_delay;
 };
 
+struct tablet_v2_path {
+   struct wl_list link;
+   char *path;
+};
+
+struct tablet_tool_info {
+   struct wl_list link;
+   struct zwp_tablet_tool_v2 *tool;
+
+   uint64_t hardware_serial;
+   uint64_t hardware_id_wacom;
+   enum zwp_tablet_tool_v2_type type;
+   
+   int tilt;
+   int pressure;
+   int distance;
+   int rotation;
+   int slider;
+   int wheel;
+};
+
+struct tablet_pad_group_info {
+   struct wl_list link;
+   struct zwp_tablet_pad_group_v2 *group;
+
+   uint32_t modes;
+   size_t button_count;
+   int *buttons;
+   size_t strips;
+   size_t rings;
+};
+
+struct tablet_pad_info {
+   struct wl_list link;
+   struct zwp_tablet_pad_v2 *pad;
+
+   uint32_t buttons;
+   struct wl_list paths;
+   struct wl_list groups;
+};
+
+struct tablet_info {
+   struct wl_list link;
+   struct zwp_tablet_v2 *tablet;
+
+   char *name;
+   uint32_t vid, pid;
+   struct wl_list paths;
+};
+
+struct tablet_seat_info {
+   struct wl_list link;
+
+   struct zwp_tablet_seat_v2 *seat;
+   struct seat_info *seat_info;
+
+   struct wl_list tablets;
+   struct wl_list tools;
+   struct wl_list pads;
+};
+
+struct tablet_v2_info {
+   struct global_info global;
+   struct zwp_tablet_manager_v2 *manager;
+   struct weston_info *info;
+
+   struct wl_list seats;
+};
+
 struct presentation_info {
struct global_info global;
struct wp_presentation *presentation;
@@ -134,6 +205,9 @@ struct weston_info {
struct wl_display *display;
struct wl_registry *registry;
 
+   struct wl_list seats; // required for tablet-unstable-v2
+   struct tablet_v2_info *tablet_info; // required for tablet-unstable-v2
+
struct wl_list infos;
bool roundtrip_needed;
 };
@@ -455,6 +529,767 @@ 

[PATCH 0/2] Add tablet_v2 support to weston-info

[wl]

From: Markus Ongyerth 

Hi,

the first commit adds support for the tablet-unstable-v2 protocol to
weston-info. It will output the currently attached tablets, tablet_pads and
tablet_tools with all info provided by the protocol.
An example output:

```
interface: 'zwp_tablet_manager_v2', version: 1, name: 11
tablet_seat: seat0
tablet: Wacom Intuos3 6x8 Pen
vendor: 1386
product: 177
path: 
/sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/0003:056A:00B1.0019/input/input106/event5
pad:
buttons: 8
path: 
/sys/devices/pci:00/:00:14.0/usb3/3-2/3-2:1.0/0003:056A:00B1.0019/input/input108/event6
group:
modes: 1
strips: 2
rings: 0
buttons: 0 1 2 3 4 5 6 7
tablet_tool: pen
hardware serial: 7803f99
hardware wacom: 823
capabilities: tilt pressure distance
```

The second patch is a mostly unrelated patch that fixes a memory-leak in
weston-info I found while searching for ones I introduced with valgrind

Cheers,
ongy

Markus Ongyerth (2):
  weston-info: Add support for tablet-unstable-v2
  weston-info: destroy wl_keyboard

 Makefile.am   |  14 +-
 clients/weston-info.c | 854 +-
 2 files changed, 859 insertions(+), 9 deletions(-)

-- 
2.17.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel