Re: CI/yaml: inlining or providing an "upstream" utility

[Peter Hutterer]

On Mon, Mar 25, 2024 at 11:19:49AM +0100, tlaro...@kergis.com wrote:
> On Mon, Mar 25, 2024 at 08:07:24PM +1000, Peter Hutterer wrote:
> > On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote:
> > > In a previous mail, I proposed, when autotools and meson are both
> > > provided to build a module, to not verify what they provide by simply
> > > diffing the resulting installation directories, but to treat pkgconfig
> > > generated *.pc files specially, by comparing them semantically and
> > > not lexically (just ensure that they "say" the same thing, with
> > > corresponding default configurations, even if they do not say it
> > > the same way---autotools uses ${variable} for some default definitions,
> > > which is not bad per se; but meson has not the same variables, and
> > > the files can end up different).
> > > 
> > > In the .gitlab-ci.yml, adding an -x '*.pc' to diff would pass these
> > > files; then comparing all the matching basename pc files would do the
> > > trick with the script I proposed previously.
> > > 
> > > The problem is: is it possible to add such a script so that it is
> > > available as an utility (like libtool and others) to the CI in the
> > > docker; or do we have to inline the command as a multi-lines script
> > > directly in the
> > > .gitlab-ci.yml file?
> > 
> > Convention is that scripts that are only used in the CI usually go into
> > .gitlab-ci/
> 
> But this does mean that I will have to copy the very same script in
> every module? And that I will have to update all the modules whenever
> I change the script?
> 
> Or, put in other words: is there a way to contribute such an
> utility---under whatever license: it's not rocket-science---to gitlab
> so that it is available for whatever module for CI?

util/modular I guess? or otherwise you put it in the logical primary
repository (whichever this is depends on the context of the patch, e.g.
libX11 for all X libraries, xserver for anything server specific etc)
and then curl the script in the gitlab ci of the dependent modules.

Cheers,
  Peter

Re: CI/yaml: inlining or providing an "upstream" utility

[Peter Hutterer]

On Mon, Mar 25, 2024 at 08:36:44AM +0100, tlaro...@kergis.com wrote:
> In a previous mail, I proposed, when autotools and meson are both
> provided to build a module, to not verify what they provide by simply
> diffing the resulting installation directories, but to treat pkgconfig
> generated *.pc files specially, by comparing them semantically and
> not lexically (just ensure that they "say" the same thing, with
> corresponding default configurations, even if they do not say it
> the same way---autotools uses ${variable} for some default definitions,
> which is not bad per se; but meson has not the same variables, and
> the files can end up different).
> 
> In the .gitlab-ci.yml, adding an -x '*.pc' to diff would pass these
> files; then comparing all the matching basename pc files would do the
> trick with the script I proposed previously.
> 
> The problem is: is it possible to add such a script so that it is
> available as an utility (like libtool and others) to the CI in the
> docker; or do we have to inline the command as a multi-lines script
> directly in the
> .gitlab-ci.yml file?

Convention is that scripts that are only used in the CI usually go into
.gitlab-ci/

Cheers,
  Peter

Re: Why does xf86-input-evdev ignore the xkb_rules option?

[Peter Hutterer]

On Mon, Mar 18, 2024 at 05:55:04PM +0100, Martin Burggraf wrote:
> Hi,
>  
> I have an input device/keyboard, which I reconfigured greatly, wrote my own 
> geometry files, symbols, keycodes and so on.
> To make it work with X11 I wanted to write my own rules file for use with the 
> xf86-input-evdev package. However I had to notice, that it doesn't work, 
> because when using
> 
> Driver "evdev"
> 
> In the Config file, the statement
> Option "XkbRules" "myfile"
> is ignored.
> 
> In  xf86-input-evdev src/evdev.c I found line 1152 and follwing:
>/* sorry, no rules change allowed for you */
> xf86ReplaceStrOption(pInfo->options, "xkb_rules", "evdev");
> rmlvo.rules = xf86SetStrOption(pInfo->options, "xkb_rules", NULL);
> 
> So the code explicitly ignores the option. As a result I have to make
> my rules changes to the file /usr/share/X11/xkb/rules/evdev itself,
> which isn't quite update stable and a hassle for me.
> 
> Is there an explanation, on why exactly the option to specify a
> different rule-file is disabled? I guess there must be a good reason,
> but I can't find any info on it.

history. 20-ish years ago there effectively used to be one ruleset
("base", "xfree86", or "xorg" depending which symlink name you used).
evdev had slightly different requirements (primarily keycodes) so a
different ruleset was used for that.

Using the xfree86 ruleset for evdev devices ended up in some keys doing
the wrong thing because the keycodes were mostly the same but differed
in a few crucial parts. But at that time everyone who ever copied the
XKB configuration from a forum also copied the line 
Option "XkbRules" "xfree86" into their xorg.conf (this was before
xorg.conf.d support).

After spending too much time on telling users to update their config
files, evdev hardcoded ruleset hardcoded to ignore the XkbRules option. 

Now it's 20-ish years later, the keyboard driver is no longer a thing on
most linux distributions and we may be able to remove that harcoded option.
Except - because we never could fix the users configurations there's a 
chance that some of these got copy/pasted through the years and will
break. Probably easier to fix now than back then, doubly so if we keep
the current behaviour by only XkbRules if it's set to "xfree86" and
friends.

All that said: I think custom rules are a little bit pointless, you
should be able to get by with the 'custom' layout in X:
https://who-t.blogspot.com/2021/02/a-pre-supplied-custom-keyboard-layout.html
IIRC that one pulls in types and symbols - I'm not sure why you'd need a
special keycode section given that the default evdev one provides all of
them. Geometry won't work but that one is mostly superfluous either way.

Cheers,
  Peter`

Re: gitlab: remove old pipelines ?

[Peter Hutterer]

On Tue, Feb 27, 2024 at 01:09:41PM +0100, Enrico Weigelt, metux IT consult 
wrote:
> Hello folks,
> 
> 
> Is there a way to actually remove old pipelines ?
> 
> Gitlab offers a "delete" button, but this doens't seem to work:
> when pressing it, the button just spins forever - and after reload
> nothing had happened - it's still there.
> 
> Is that a gitlab bug ?

why do you need to remove them? iirc the artifacts stay around for the
specified time only anyway and I doubt the storage needed by the
pipelines otherwise has much of an effect on anything.

Cheers,
  Peter

Re: Can we rely on #pragma once ?

[Peter Hutterer]

On Mon, Feb 19, 2024 at 03:02:18PM +0100, Mark Kettenis wrote:
> > Date: Mon, 19 Feb 2024 12:13:34 +0100
> > From: "Enrico Weigelt, metux IT consult" 
> > 
> > Hello folks,
> 
> Hi Enrico,
> 
> > we've got a lot of include files, therefore lots of guards.
> > 
> > Modern C compilers should understand #pragma once, but this isn't
> > without problems (possibly problematic with symlinks ?), and I have
> > to admit I don't how well is it supported outside of GNU land.
> > 
> > Can we rely on it ?
> 
> IMHO, no.  There must be a reason why this hasn't been widely adopted,
> despite having been around for the better part of 2- years.  

maybe just inertia? the ifdef guards work just fine, pragma is nice for
new headers but few people would be motivated to go and replace all
ifdefs to pragmas just for entertainment value.

meson uses pragma once for its generated headers (e.g. dix-config.h) so
any compiler that managed to build an X server recently supports it.

> And the
> public Xorg headers should work with a standard C99 compiler.
> 
> To be honest, some of the things you've raised in this thread really
> worry me.  I don't think Xorg is in a position where it makes sense to
> do a large overhaul.  The code is used by a lot of projects, but many
> of those projects probably don't have a lot of manpower to spend on
> testing Xorg patches.  So breakage may not be caught in a timely
> fashion unless you commit yourself to testing a wide variety of
> platforms.

fully agree here. *we* don't have the manpower to test those patches,
the CI is nice and worlds better than what we used to have (which was,
well, nothing) but it's not going to catch much beyond build errors.

Cheers,
  Peter
 
> Looking at this particular thing, what problem are you trying to
> solve?  The existing header files already have the protection in place
> where it matters.  And I don't expect why software that's mostly just
> in maintenance mode would see a lot of new header files being added.


> 
> > In fact, we already have one place using it:
> > 
> > include/xwayland-config.h.meson.in
> > 
> > But I doubt that xwayland is ever been compiled w/ non-gnu/non-clang
> > compilers.

marge-bot enabled on the xserver repo

[Peter Hutterer]

Just a heads-up, I've enabled marge-bot on the xserver repo so from now
on please assign to @marge-bot to get the MR to merge which will then do
the right thing (whatever it already does in mesa and other projects,
it's all the same commandline anyway).

Advantages include easier merging of multiple MRs (no more waiting) and
a backlink to the MR (Part-Of: ) for future reference. Those two were
really the seller for me.

Cheers,
  Peter

Re: Licenses: being finicky

[Peter Hutterer]

On Fri, Feb 16, 2024 at 12:42:29PM +0100, tlaro...@kergis.com wrote:
> On Fri, Feb 16, 2024 at 08:22:59PM +1000, Peter Hutterer wrote:
> > On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> > > Some meson.build, for example, have a SPDX-License-Identifier: tag,
> > > where "MIT" is mentionned, applying (I think) to the file itself, and
> > > the project has an entry with a pair (license: 'MIT') applying to the
> > > data by itself.
> > > 
> > > But, for example, xcbproto has a license with a (classical, for me)
> > > fourth clause forbiding use of the names of the authors without
> > > permission to advertise etc.
> > > 
> > > Acoording to:
> > > 
> > > https://spdx.org/licenses/
> > > 
> > > this is identified as "X11", the "MIT" being the same without this
> > > fourth paragraph. (I suspect this distinction is rather new.)
> > > 
> > > When creating meson files for building, is there some rule regarding
> > > this? 
> > > 
> > > I think that the correct way is to state 'X11' or 'MIT' or
> > > whatever matches COPYING or COPYRIGHTS or whatever file explains the
> > > license status and to conform, simply because this exists and is
> > > standardized, to the SPDX list of identifiers.
> > > 
> > > What do other think about this?
> > 
> > we've recently done this work for Fedora so you can probably get the
> > various licenses from there. Fun fact, some projects have *a lot* of
> > SPDX identifers (i think the record is 15).
> > 
> > In the end whether the license entry in meson.build matters is very
> > questionable and only the actual code files and maybe COPYING matters
> > (but do ask your preferred lawyer for confirmation).
> 
> Since a packaging system using meson could advertise the license
> from what is set in the project in meson.build, 

Maybe in a perfect world but this is not a reliable indicator so I doubt
any packaging system that cares about licenses uses that, or can use it
for the forseeable future.  Meson doesn't do any verification of those
tags so aside from being easier to extract it's really no different to
relying on COPYING or LICENSE (the latter of which at least github
encourages you to add).

> I think that it should be set
> right there and perhaps conforming to the SPDX identifiers (the SPDX
> identifiers in the meson.build meson_options.txt are less crucial, one
> could infer that if someone---me for example---is contributing, he's
> willing to contribute under X11 license and that this is what applies
> if lacking a more defined license identifier).

ftr, I don't disagree, we should advertise the right license whereever
possible but, example of the xserver: 
  Adobe-Display-PostScript AND BSD-3-Clause AND DEC-3-Clause AND
  HPND AND HPND-sell-MIT-disclaimer-xserver AND HPND-sell-variant AND
  ICU AND ISC AND MIT AND MIT-open-group AND NTP AND SGI-B-2.0 AND
  SMLNJ AND X11 AND X11-distribute-modifications-variant

I'm sure that would scare a few people away ;)

Sure, you could reduce it to just whatever the top-level spdx license is
(MIT) but then you're just back at where you started.

A better option for this would be the relatively new `license_files`
kwarg in meson's project() which we can just point at COPYING. But
having to version-check meson just to add this seem a bit over the top.

TLDR: our COPYING files are (thanks to Alan) quite good so relying on
those is probably the least friction approach.

Changing 'mit' to 'x11' in projects where it's really just the once
license would be quite uncontroversial though.
 
Cheers,
  Peter

> > 
> > Licenses are also compatible or direct derivatives of each other so X11
> > and MIT are compatible and unless you're into lawyerese it doesn't
> > matter which one is listed in meson.build.
> > 
> > > Note: I'm not planing to review "correct" attribution between X11 and
> > > MIT in all the Xorg projects---I'm sufficiently late on my schedule
> > > with what I have to do without starting to rover around. Furthermore,
> > > X11 has been historically identified as 'MIT'...
> > 
> > The main question: what are you're trying to achieve here? The
> > vast majority of our projects are old and new projects tend to
> > (or should) copy/paste from SDPX anyway.
> 
> I'm just _adding_ (not removing autoconf/automake stuff) meson build
> files to Xorg projects I'm reviewing (because I need to track bugs with
> X11/Mesa and kernel DRMKMS on NetBSD), so I want to have everything as
> correct as possible.
> 
> > 
> > PS: If I were you I'd be *really* careful trying to update old
> > repositories. We've made people maintainers for less! ;)
> 
> I will be careful ;)
> -- 
> Thierry Laronde 
>  http://www.kergis.com/
> http://kertex.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: Licenses: being finicky

[Peter Hutterer]

On Wed, Feb 14, 2024 at 09:37:43PM +0100, tlaro...@kergis.com wrote:
> Some meson.build, for example, have a SPDX-License-Identifier: tag,
> where "MIT" is mentionned, applying (I think) to the file itself, and
> the project has an entry with a pair (license: 'MIT') applying to the
> data by itself.
> 
> But, for example, xcbproto has a license with a (classical, for me)
> fourth clause forbiding use of the names of the authors without
> permission to advertise etc.
> 
> Acoording to:
> 
> https://spdx.org/licenses/
> 
> this is identified as "X11", the "MIT" being the same without this
> fourth paragraph. (I suspect this distinction is rather new.)
> 
> When creating meson files for building, is there some rule regarding
> this? 
> 
> I think that the correct way is to state 'X11' or 'MIT' or
> whatever matches COPYING or COPYRIGHTS or whatever file explains the
> license status and to conform, simply because this exists and is
> standardized, to the SPDX list of identifiers.
> 
> What do other think about this?

we've recently done this work for Fedora so you can probably get the
various licenses from there. Fun fact, some projects have *a lot* of
SPDX identifers (i think the record is 15).

In the end whether the license entry in meson.build matters is very
questionable and only the actual code files and maybe COPYING matters
(but do ask your preferred lawyer for confirmation).

Licenses are also compatible or direct derivatives of each other so X11
and MIT are compatible and unless you're into lawyerese it doesn't
matter which one is listed in meson.build.

> Note: I'm not planing to review "correct" attribution between X11 and
> MIT in all the Xorg projects---I'm sufficiently late on my schedule
> with what I have to do without starting to rover around. Furthermore,
> X11 has been historically identified as 'MIT'...

The main question: what are you're trying to achieve here? The
vast majority of our projects are old and new projects tend to
(or should) copy/paste from SDPX anyway.

Cheers,
  Peter

PS: If I were you I'd be *really* careful trying to update old
repositories. We've made people maintainers for less! ;)

Re: gitlab: failing check-merge-request on non MR branches

[Peter Hutterer]

On Thu, Feb 15, 2024 at 12:15:52PM +0100, Enrico Weigelt, metux IT consult 
wrote:
> Hello friends,
> 
> 
> is it intended that the check-merge-request job is always failing on
> non MR branches ?

See commit 88637d42dbc5c488c9a75a6042e6778c4928b007 in ci-templates for
the motivation. I think that default has been fixed in gitlab since
(can't immediately find a setting for it though). Now that we have
workflows we can probably make that job dependent on
CI_PIPELINE_SOURCE == 'merge_request_event' or something.

Cheers,
  Peter

> Fortunately it's just classified as warning instead of fail, but still
> troubling: either one has to check the indivual job results or risks
> not noticing other warnings that indeed are also relevant for non-MRs.
> 
> 
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[Peter Hutterer]

On Tue, Feb 06, 2024 at 11:41:06AM +0100, Enrico Weigelt, metux IT consult 
wrote:
> On 05.02.24 22:56, Peter Hutterer wrote:
> 
> > Best approach is to add a line "Fixes #123" into the commit message
> > and/or the merge request and gitlab will automatically link to to issue
> > 123 in the same repo and close it when merged.
> 
> I believe gitlab reacts on "Closes:", like this:
> 
> Closes: xorg/xserver#1631

It supports that too, but afaik the use of Fixes is more common in the
xorg repo. In (some?) gnome OTOH repos Closes refers to an issue anf
Fixes usually to a commit.

> By the way: how to do we handle fixes that might go to several branches ?

merge it into master, then `git cherry-pick -x` to the branch, file a
merge request for that particular branch. The gitlab closed merge
request page will have examples of those, usually prefixed with the
branch they're supposed to be merged in to make them easier to identify.

Cheers,
  Peter

> 
> For example, we might have have things that should go to 21.x branch
> as well as master, as well as xwayland branch.
> 
> 
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

Re: issues and merge requests

[Peter Hutterer]

On Mon, Feb 05, 2024 at 09:52:50PM +0100, tlaro...@kergis.com wrote:
> Alan Coopersmith has applied the merge request for libXau---thanks!
> 
> I had written 2 issues, related, against libXau, that the patches
> address, so I have closed the issues after the merge.
> 
> It seems to me that writing issues against a module; providing patches
> via a merge request; then closing the issues when the merge has been
> approved and applied by a developer has the advantage of providing an
> history.
> 
> Are there guidelines set concerning this?

Best approach is to add a line "Fixes #123" into the commit message
and/or the merge request and gitlab will automatically link to to issue
123 in the same repo and close it when merged.

Otherwise and if on the same instance, you can also link to other
projects using the full path including namespace, e.g.
xorg/lib/libX11!10 is merge request 10 in libX11.

Note that a "Fixes #123" in a commit message will link from the issue to
the commit every time you push. If you're easily embarrassed about your
development flow it's best to leave that off and add it before the final
push before filing a merge request ;)

Cheers,
  Peter

Re: Fork permissions on gitlab

[Peter Hutterer]

On Wed, Jan 31, 2024 at 12:21:58PM +0100, Enrico Weigelt, metux IT consult 
wrote:
> Hello folks,
> 
> 
> any operator here who could grant me fork permission in gitlab ?
> I'm currently preparing several patch queues I'd like to submit.

Please see
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home#how-can-i-contribute-to-an-existing-project-or-create-a-new-one

Cheers,
  Peter


> 
> 
> thanks,
> --mtx
> 
> --
> ---
> Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
> werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
> GPG/PGP-Schlüssel zu.
> ---
> Enrico Weigelt, metux IT consult
> Free software and Linux embedded engineering
> i...@metux.net -- +49-151-27565287

Re: Release of access to Logs environment CI - GitLab- Xorg

[Peter Hutterer]

Hi Willian,

On Mon, Jun 19, 2023 at 01:23:18PM -0300, Willian Mendonça wrote:
[...]
> To perform better validations of our approaches, we have developed a tool
> for downloading and mining logs:
> https://github.com/jacksonpradolima/gitlabci-torrent. However, in order to
> use this tool, we need to obtain access permission from you, as the Gitlab
> API returns a "not found" error due to access restrictions through the API,
> when we tried to mine Xorg(in specific the x-server project) repository
> logs: https://gitlab.freedesktop.org/xorg/xserver.
> 
> To try to explain better what I need access rights, just to be able to
> download the CI logs. This access can be read-only access via the REST API
> (i.e. personal token with read_api (
> https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#personal-access-token-scopes)
> scope. If it is possible to release this access, it can be using the github
> account itself.

Filing an issue [1] should do the trick, see [2] for more info on all
that:
[1] 
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/new?issuable_template=User%20verification
[2] 
https://gitlab.freedesktop.org/freedesktop/freedesktop/-/wikis/home#to-request-the-capability-to-createfork-projects-please-file-an-issue

Cheers,
  Peter

Re: X11 based application does not respond to touch after first touch ( ILI210x Touchscreen)

[Peter Hutterer]

On Thu, Jun 08, 2023 at 12:31:51PM +0530, Vishnu Motghare wrote:
> Hi Peter,
> 
> Thanks for your reply.
> 
> I'm using xf86-input-tslib
> <https://layers.openembedded.org/layerindex/recipe/301409/>  & not
> libinput. can xf86-input-tslib
> <https://layers.openembedded.org/layerindex/recipe/301409/>  handle the
> pressure? Also how to capture events from tslib input driver?

libinput record sits below the drivers so that will work either way
(should be called `kernel record` but oh well). As for tslib - no idea,
sorry, the little that I knew about it I have well and truly forgotten.

Cheers,
  Peter

> 
> Regards,
> Vishnu
> 
> On Thu, 8 Jun 2023 at 08:30, Peter Hutterer 
> wrote:
> 
> > On Wed, Jun 07, 2023 at 01:04:02PM +0530, Vishnu Motghare wrote:
> > > Hello All,
> > >
> > > X11-based applications like xterm & xinput_calibrator do not respond to
> > > touch after the first touch.
> > >
> > > We have an ILI210x Touchscreen controller & the kernel version is 5.15,
> > > touch was working fine with the 5.4 kernel version with Xterm &
> > > xinput_calibrator
> > >
> > > This is the  Commit
> > > <
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/input/touchscreen/ili210x.c?h=v5.10.182=3a492e4403ee2e3442397230d68e26e81525af90
> > >
> > >   added
> > > in the kernel to report the pressure value & after this, no X11-based
> > > application works after the first touch
> > >
> > > Do we need to add any setting in xorg.conf to handle the pressure value
> > > reported by  ILI210x Touchscreen?
> >
> > Most likely you're using the xf86-input-libinput driver for touchscreens
> > (unless you explicitly changed it to use the evdev driver). In that case
> > you can check with `libinput debug-events` to see what libinput produces
> > - the xorg libinput driver is a fairly thin wrapper and this should give
> > you a good indication of where things go wrong.
> >
> > libinput record works either way and shows you the events produced by
> > the kernel.
> >
> > also, fwiw libinput does not handle pressure for touch screen events so
> > this patch shouldn't have made a difference in userspace. So there's
> > most likely some other event missing, libinput record should show this.
> > Probably best to file an issue against libinput for that.
> >
> > Cheers,
> >   Peter
> >
> >

Re: X11 based application does not respond to touch after first touch ( ILI210x Touchscreen)

[Peter Hutterer]

On Wed, Jun 07, 2023 at 01:04:02PM +0530, Vishnu Motghare wrote:
> Hello All,
> 
> X11-based applications like xterm & xinput_calibrator do not respond to
> touch after the first touch.
> 
> We have an ILI210x Touchscreen controller & the kernel version is 5.15,
> touch was working fine with the 5.4 kernel version with Xterm &
> xinput_calibrator
> 
> This is the  Commit
> 
>   added
> in the kernel to report the pressure value & after this, no X11-based
> application works after the first touch
> 
> Do we need to add any setting in xorg.conf to handle the pressure value
> reported by  ILI210x Touchscreen?

Most likely you're using the xf86-input-libinput driver for touchscreens
(unless you explicitly changed it to use the evdev driver). In that case
you can check with `libinput debug-events` to see what libinput produces
- the xorg libinput driver is a fairly thin wrapper and this should give
you a good indication of where things go wrong.

libinput record works either way and shows you the events produced by
the kernel.

also, fwiw libinput does not handle pressure for touch screen events so
this patch shouldn't have made a difference in userspace. So there's
most likely some other event missing, libinput record should show this.
Probably best to file an issue against libinput for that.

Cheers,
  Peter

Re: Making new releases of X.Org modules

[Peter Hutterer]

On Thu, Dec 08, 2022 at 12:34:33PM -0800, Alan Coopersmith wrote:
> On 12/7/22 19:07, Peter Hutterer wrote:
> > fwiw, I've done similar things in the past, pushing a release out just
> > to make some internal processes easier. It's simpler to update to a new
> > version than shipping the one patch that's actually needed (and all
> > other patches are just readme changes and whatnot).
> > 
> > But for me, the threshold is the tarball, not the installed files.
> > The only time I wouldn't create a release is when the tarball is
> > effectively identical. Which is basically anything that's CI-only.
> > But anything that affects the delivered tarball can be subjected to a
> > release.
> 
> Fair enough.
> 
> > This goes doubly now that many repos have changed to xz so we have a mix
> > of tarball types too. Releasing everything in one group to get some
> > consistency is useful.
> 
> That almost sounds katamari-like. Fortunately, we're getting most things
> released without the overhead of a katamari release anyway.

biggest difference between now and the katamaris is that while 
consistency is useful, if it takes a few months to get every package to
catch up it's not a big deal, no need for the flag-day stress of the
katamari.

Also for clarification, I meant "releasing everything that belongs to
one group", e.g. releasing all the font modules so they are consistent
with each other. I didn't mean release everything *as* one group, too
much effort, that :)

> > And as the font bugs show, sometimes a release is warranted just to
> > update the tarball with more modern generated files.
> 
> Yeah - I know they can just run autogen.sh or autoreconf to get their
> builds to work, but I know it's less work to just have upstream usable
> right out of the tarball.  (And of course, once everything builds with
> meson and the autoconf infrastructure is removed, that goes away, but
> we don't have enough people converting modules to meson to see that yet.)

Given that there's still too much documentation that refers to only
running configure on tarballs, I agree, they should be usable as-is
without autoreconf.

Cheers,
  Peter

> > IOW, let's not worry about whether releases happen too often, it's a lot
> > easier for distributions to ignore a released tarball than it is to wish
> > a newer one into existence :) Especially since "too often" here still
> > means years in between the releases anyway.
> 
> Okay - I guess I just see things like
> https://repology.org/project/fonts:adobe-100dpi/versions
> or
> https://repology.org/project/libx11/versions
> and think about how many different packagers I'm making do work, but
> if that work is just changing the version number of the tarball they
> download, they should have that pretty well automated by now.

Re: Making new releases of X.Org modules

[Peter Hutterer]

On Wed, Dec 07, 2022 at 05:37:27PM -0800, Alan Coopersmith wrote:
> Normally when I go through the list of modules which have had git commits
> since their last release was tagged to decide what to make new releases of,
> I skip over those which only have changes that don't really affect the
> installed files, such as the changes for migrating to gitlab, autogen
> script updates, CI updates, changing the tarball type from .bz2 to .xz, etc.
> 
> This has resulted in some modules not getting released in many years.
> For instance most of the font modules were last released in 2010, but
> have an assortment of small changes we could release, like:
> https://gitlab.freedesktop.org/xorg/font/adobe-100dpi/-/commits/master
> but which wouldn't result in any changes I see to the installed font files.
> 
> But we keep getting bugs filed for the ancient generated autoconf scripts
> not recognizing new platforms like RISC-V, such as the 4 "BUILD FAIL" bugs
> on https://gitlab.freedesktop.org/groups/xorg/font/-/issues .
> 
> And I've had another distro packager email me recently asking to make
> new releases of various drivers, such as all the xf86-video-sun* modules.
> 
> Am I being too picky about deciding if a release is warranted?  Is it
> going to annoy other distro packagers if we make a few more releases
> than we have before?  (Maybe ship font package updates every 6 years
> instead of waiting for 12?)
> 
> Honestly, from a purely selfish point of view with my day job hat on,
> having a few more releases helps us since our policy requires reviewing
> any FOSS package that hasn't had an upstream release in the past few years
> to verify it's not dead/abandoned/etc. and it's less work for me to
> make a quick package release than it is to go through our review process.
> (Which is admittedly why there have been a number of recent releases that
>  just fix compiler & cppcheck warnings when there's nothing else to do.)

fwiw, I've done similar things in the past, pushing a release out just
to make some internal processes easier. It's simpler to update to a new
version than shipping the one patch that's actually needed (and all
other patches are just readme changes and whatnot).

But for me, the threshold is the tarball, not the installed files.
The only time I wouldn't create a release is when the tarball is
effectively identical. Which is basically anything that's CI-only.
But anything that affects the delivered tarball can be subjected to a
release.

This goes doubly now that many repos have changed to xz so we have a mix
of tarball types too. Releasing everything in one group to get some
consistency is useful.

And as the font bugs show, sometimes a release is warranted just to
update the tarball with more modern generated files.

IOW, let's not worry about whether releases happen too often, it's a lot
easier for distributions to ignore a released tarball than it is to wish
a newer one into existence :) Especially since "too often" here still
means years in between the releases anyway.

Cheers,
  Peter

Re: 504 to gitlab.freedesktop.org

[Peter Hutterer]

On Sun, Jun 12, 2022 at 05:57:05PM -0700, Jeremy Sequoia wrote:
> Hey folks,
> 
> I was going to spend a little bit of time putting out an update to XQuartz
> to address a few bugs that I've been meaning to squash, but I'm having a bit
> of an issue pulling down sources.
> 
> Fetching via ssh://g...@gitlab.freedesktop.org is giving me Permission denied
> (publickey,keyboard-interactive).  I'm not sure if the latter is an infra
> issue or if the ssh key I have stored in my gitlab account are out of date
> (it's been about a year since I touched this).  Unfortunately, I can't seem
> to access https://gitlab.freedesktop.org to check as it's constantly
> presenting me a 504 Gateway timeout.
> 
> Is anyone else able to pull sources via ssh://g...@gitlab.freedesktop.org
> right now?  Is someone looking into the 504 issue?

not an fdo admin but judging by the chatter on #freedesktop: no and yes, in
that order. seems like the infrastructure is in various stages of depositing
fecal matter on itself and the fixes are involved enough that the admins have
to be mentally awake, not merely physically.

Cheers,
  Peter

Re: Buildability of the Xorg drivers

[Peter Hutterer]

On Thu, Feb 03, 2022 at 02:07:08AM +, Zack Rusin wrote:
> 
> 
> > On Feb 2, 2022, at 15:27, Matt Turner  wrote:
> > 
> > On Sun, Jan 30, 2022 at 4:16 PM Alan Coopersmith
> >  wrote:
> >> xf86-input-vmmouse
> >> xf86-video-vmware
> >>   - do not allow merge requests
> > 
> > This has been an issue before, in conjunction with not even knowing
> > who the nominal maintainer was. E.g. someone submitted a patch almost
> > a year ago 
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.x.org%2Farchives%2Fxorg-devel%2F2021-March%2F058688.htmldata=04%7C01%7Czackr%40vmware.com%7C28b295c074264147244e08d9e68a7838%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637794304668232703%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Zj%2Fnj4NL4pRtM7Cb0AwzAQlZQFMYBS3kDQhTtAfqUXU%3Dreserved=0
> > after asking on IRC how to make a merge request and being told...
> > dunno, looks like you can't? Can we just turn on MRs for these
> > projects?
> > 
> > I see Zack recently joined the project on Gitlab and pushed to master,
> > so Cc'ing him.
> 
> Hey, yes, that’s correct, I’ll be maintaining those drivers going forward. 
> 
> I did enable MR’s on xf86-video-vmware. I’m actually not a member of
> xf86-input-vmmouse so if someone could add me then I’ll enable MR’s in there
> as well.

Turns out I had sufficient superpowers on vmmouse to do exactly that. All hail
to the new maintainer.

Cheers,
  Peter

Re: tarball types (was: [ANNOUNCE] xf86-input-libinput 1.2.1)

[Peter Hutterer]

On Mon, Jan 24, 2022 at 03:53:23PM -0800, Alan Coopersmith wrote:
> On 1/23/22 21:18, Peter Hutterer wrote:
> > xf86-input-libinput 1.2.1 is now available. Primarily a few typos and misc
> > minor fixes, the most visible change to distributions is that we now ship an
> > xz tarball instead of bz2. Due to a global shortage of flying cars, you will
> > have to accept that as your "welcome to the future" present. If you don't 
> > like
> > the future (and who can blame you!), we still have gz tarballs, simply
> > because I didn't realize we still generated those until I typed out this
> > email.
> 
> While I've been applying this change across the Xorg modules, I've followed
> the lead of those who came before me, and just replaced "dist-bz2" with
> "dist-xz".  To get rid of the gzip files we'd also have to add "no-dist-gzip"
> to our AM_INIT_AUTOMAKE() options.
> 
> Since it's been a decade since GNOME switched to exclusively releasing xz
> tarballs [1], I would expect there being no major headaches to us doing the
> same now, we just hadn't thought much about it. Is this something we want to
> do?  Does anyone have a reason we shouldn't stop making .gz files?
> (It looks like xwayland is already doing xz-only releases now.)

anything that uses meson is .xz only, so that'd explain xwayland and will soon
explain anything else that switches (e.g. xkeyboard-config is going to be
meson-only too with the next release).

Cheers,
  Peter

Re: xinput: HUION H420 Pen: XChangeDeviceProperty: data: format questions.

[Peter Hutterer]

On Fri, Jun 11, 2021 at 12:46:59AM -0500, Mike Mestnik wrote:
> Plz redirect me to where I can get assistance with this...
> 
> Hello,
>   Using the xinput cmdline tool I'm fully able to leverage my
> understanding of the HUION H420 Pen and it's properties.  When using
> xfconf-query I don't believe the data is being constructed correctly
> for passing to XChangeDeviceProperty.
> 
> https://gitlab.xfce.org/xfce/xfce4-settings/-/blob/bd2da4ed559eec4144ed8ea6092642deee63de9f/xfsettingsd/pointers.c#L866
> I'm wondering what the format of this buffer should be?
> 
> I'm trying to setup a translation matrix for a tablet(actually the
> pen). In xinput I get `Coordinate Transformation Matrix (157):
> -1.10, 0.30, 1.50, 0.70, -1.90, 1.00,
> 0.00, 0.00, 1.00`, the command issued is `xfconf-query -c
> pointers -p /HUION_H420_Pen_Pen_0/Properties/Coordinate_Transformation_Matrix
> -n -t double -s -1.1 -t double -s 0.2 -t double -s 0.3 -t double -s
> 0.4 -t double -s 1.5 -t double -s 1.6 -t double -s 0.7 -t double -s
> 0.8 -t double -s -1.9` Obviously it looks like xfconf-query's backed
> is expecting two values per cell?  Because of the code in pointers.c
> it's impossible to send more than 9 values, the counts won't match and
> the function returns early.  I therefore think that the buffer's
> format is incorrectly understood.

Don't know anything about xfconf-query but the property format is one float
per array element, but because of historical reasons the array itself must
be longs as you pass it into Xlib. I'll be a 32 bit value on the wire then.
I recommend using XIChangeProperty instead which doesn't have this issue and
XI2 has been around since 2008 now.

See DeviceSetProperty() in xserver/dix/devices.c for the server-side code of
this.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing a bug in Synaptics driver but autogen ignores prefix

[Peter Hutterer]

On Mon, Nov 30, 2020 at 07:29:29PM +0100, Andrea G. Monaco wrote:
> 
>  >  I don't think there's a configure flag for it but you can hack around that
>  >  locally.
> 
> 
> Thanks Peter, now I found it.
> 
> But I'm still perplexed: I think that a software package should fully
> respect the prefix it is given at configuration time.
> Think about the most common GNU+Linux distributions: they usually put
> package files as managed by their package systems under the /usr tree and
> leave /usr/local for software built locally, for example using the
> autotools (which in fact use /usr/local as default prefix).
> 
> What do you think about modifying this? Could it break something else?

historically, many users who installed drivers in different prefixes than
the X server ended up with a nonworking display server stack. while it's
possible to install a driver in /usr/local and then point the server to it
it's more fiddly and has more avenues of going wrong. This again results in
more bug reports which few people have the time to help with and overall a
worse experience. This is doubly so with unmaintained parts of the stack
(like the synaptics driver).

So while it's cleaner to install in /usr/local, I'd say just bite the bullet
and install in the xserver prefix. if you don't have the system-provided
synaptics package installed, it won't get overwritten on updates anyway.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: Fixing a bug in Synaptics driver but autogen ignores prefix

[Peter Hutterer]

On Mon, Nov 30, 2020 at 02:17:53AM +0100, Andrea G. Monaco wrote:
> Hello everyone,
> 
> 
> I'm trying to understand and maybe fix a slightly annoying bug in the
> Synaptics driver 1.9.1: sometimes the touchpad cursor on my Acer Aspire
> E15 starts flickering or clicking furiously or stops; at times resetting
> the touchpad (using the Fn keys) is enough to solve the problem, other
> times I need to reboot the server.
> 
> Anyway, I'm configuring xf86-input-synaptics module with
> --prefix=/usr/local (which is the default prefix by the way) and after 'export
> PREFIX=/usr/local', but make install insists on installing a header file under
> /usr/include, which I don't like because it would overwrite the already
> existing one.
> 
> Is this behavior expected? I'm no expert in X, so please be patient if
> my question sounds dumb. Also I found a bug report about xkb ignoring
> prefix too.
> If it's a bug in the autotools setup I can work on it.

see configure.ac, the headers are installed into the 'sdkdir':

# X Server SDK location is required to install Synaptics header files
# This location is also relayed in the xorg-synaptics.pc file
sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server`
AC_SUBST([sdkdir])

I don't think there's a configure flag for it but you can hack around that
locally.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: release fonttosfnt 1.1.1 ?

[Peter Hutterer]

Hi Matthieu,

On Sun, Oct 18, 2020 at 10:18:42AM +0200, Matthieu Herrb wrote:
> Would you be ok if I make a release of xfonttosfnt (or if you have
> some time to do it on your side) to make the recent
> work of Christopher Zimmerman and others available ?
> 
> With the removal of bitmapped fonts support in pango, there is some
> real need for this.

Please go for it, I make no maintenance claim to fonttosfnt whatsoever ;)
It'd likely take me a few days before I'd get to it.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

new tool - xisxwayland

[Peter Hutterer]

Hi all,

I'm planning to move this little tool to the xorg/app folder, but I'd like
to double-check that we don't already have something like this:
https://gitlab.freedesktop.org/whot/xisxwayland/

it's a tiny C program that connects to the X server and exits with status 0
if the X server is Xwayland, or 1 otherwise. To be used in shell scripts,
modeled after the selinuxenabled command:

if xisxwayland; then
   echo "don't bother runing xinput, you're on wayland"
fi

It currently uses RandR output names to check but if that ever changes, we
can change this accordingly.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Peter Hutterer]

On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote:
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne  wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > > For Mesa, we could run CI only when Marge pushes, so that it's a 
> > > > > strictly
> > > > > pre-merge CI.
> > > >
> > > > Thanks for the suggestion! I implemented something like this for Mesa:
> > > >
> > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> > > >
> > >
> > > I wouldn't mind manually triggering pipelines, but unless there is
> > > some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> > > click first the container jobs.. then wait.. then the build jobs..
> > > then wait some more.. and then finally the actual runners.  That would
> > > be a real step back in terms of usefulness of CI.. one might call it a
> > > regression :-(
> >
> > On GStreamer side we have moved some existing pipeline to manual mode.
> > As we use needs: between jobs, we could simply set the first job to
> > manual (in our case it's a single job called manifest in your case it
> > would be the N container jobs). This way you can have a manual pipeline
> > that is triggered in single (or fewer) clicks. Here's an example:
> >
> > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292
> >
> > That our post-merge pipelines, we only trigger then if we suspect a
> > problem.
> >
> 
> I'm not sure that would work for mesa since the hierarchy of jobs
> branches out pretty far.. ie. if I just clicked the arm64 build + test
> container jobs, and everything else ran automatically after that, it
> would end up running all the CI jobs for all the arm devices (or at
> least all the 64b ones)

generate your gitlab-ci from a template so each pipeline has its own job
dependency. The duplication won't hurt you if it's expanded through
templating and it gives you fine-grained running of the manual jobs.

We're using this in ci-templates/libevdev/libinput for the various
distributions and their versions so each distribution+version is effectively
its own pipeline. But we only need to maintain one job in the actual
template file.

https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-ci-yml

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

[Peter Hutterer]

On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer  wrote:
> >
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I implemented something like this for Mesa:
> >
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
> >
> 
> I wouldn't mind manually triggering pipelines, but unless there is
> some trick I'm not realizing, it is super cumbersome.  Ie. you have to
> click first the container jobs.. then wait.. then the build jobs..
> then wait some more.. and then finally the actual runners.  That would
> be a real step back in terms of usefulness of CI.. one might call it a
> regression :-(

I *think* this should work though if you set up the right job dependencies.
very simple example:
https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128601

job1 is "when:manual", job2 has "needs: job1", job3 has "needs: job2".
Nothing runs at first, if you trigger job1 it'll cascade down to job 2 and
3.

The main limit you have here are the stages - where a job is part of a stage
but does not have an explicit "needs:" it will wait for the previous stage
to complete. That will never happen if one job in that stage has a manual
dependency. See this pipeline as an example:
https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128605

So basically: if you set up all your jobs with the correct "needs" you could
even have a noop stage for user interface purposes. Here's an example:
https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128606

It has a UI stage with "test-arm" and "test-x86" manual jobs. It has other
stages with dependent jobs on those (cascading down) but it also has 
a set of autorun jobs that run independent of the manual triggers. When you
push, the autorun jobs run. When you trigger "test-arm" manually, it
triggers the various dependent jobs.

So I think what you want to do is possible, it just requires some tweaking
of the "needs" entries.

Cheers,
   Peter

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: US International (AltGr dead keys) and Ł

[Peter Hutterer]

On Sat, Mar 14, 2020 at 10:06:54AM -0500, Justin Eberlein wrote:
> The US international (AltGr dead keys) layout has two Πkeys. Is it
> possible to move Ø from L to K, make X the only Œ key, and make L Ł instead?

https://gitlab.freedesktop.org/xkeyboard-config/ is where you can file an MR
for this. I personally don't see an issue with changing K since it's a
duplicate now, moving other things around is probably going to generate
hatemail...

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: X.Org modules which could use some help to release

[Peter Hutterer]

On Sun, Jul 14, 2019 at 06:34:20PM -0700, Alan Coopersmith wrote:
> As you may have noticed, I've been working through the various modules to make
> releases of those with significant enough change to justify a release (i.e.
> more than just the autogen.sh cleanups & gitlab README/configure.ac updates).
> 
> There's some modules which have more than enough change that I've left for
> now for other reasons, which others could help with:
> 
> app/mkcomposecache:
>   - Does anyone actually use this?  I think the code to read the files is
> in Xlib, but do packagers ship this to build the files?
> 
> app/twm:
>   - Needs someone to evaluate:
> https://gitlab.freedesktop.org/xorg/app/twm/issues/7
> https://patchwork.freedesktop.org/project/Xorg/list/?q=twm
> patches in https://gitlab.freedesktop.org/xorg/app/twm/issues
> 
> app/xkbcomp:
>   - Needs someone to evaluate:
> https://patchwork.freedesktop.org/project/Xorg/list/?q=xkbcomp
> https://gitlab.freedesktop.org/xorg/app/xkbcomp/issues

working my way through those, even if it largely means closing those old
enough to attend school.
 
> app/xkbutils:
>   - Needs someone to evaluate:
> patch in https://gitlab.freedesktop.org/xorg/app/xkbutils/issues/1

I'll stare at that tomorrow and then probably wave it through.

Cheers,
   Peter

> 
> app/xrandr:
>   - Needs someone to evaluate:
> https://gitlab.freedesktop.org/xorg/app/xrandr/merge_requests/1
> https://patchwork.freedesktop.org/project/Xorg/list/?q=xrandr
> 
> app/xrestop:
>   - Are we shipping this as an X.Org project now despite the GPL license?
>   - Previous releases are on yoctoproject.org, not xorg.freedesktop.org -
> do we care about that?
> 
> app/xresponse:
>   - I didn't even know this existed until seeing it in gitlab, but it's
> apparently another GPL project we inherited from openedhand.
> It looks like it's been abandoned since 2007 - does anyone use it
> or should it just be archived now?
> 
> app/xscope:
>   - I pushed the fixes to show peer process info on Linux & Solaris.
> Does anyone want to provide support for any other platforms before we
> ship this?  See:
> https://lists.x.org/archives/xorg-devel/2019-February/057982.html
> 
> app/xshowdamage:
>   - This appears to be test code, never released as a tarball, but might
> still be useful for debugging, so I don't think it should be archived.
> 
> driver/xf86-input-keyboard:
>   - Needs a FreeBSD person to figure out the correct patch to apply for:
> https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/issues/28
> 
> driver/xf86-video-dummy:
>   - Needs someone to evaluate:
> 
> https://gitlab.freedesktop.org/xorg/driver/xf86-video-dummy/merge_requests/1
> 
> These I left because I believe they have maintainers to handle their releases
> (or to decide whether it's time for a release or not):
>   - app/intel-gpu-tools
>   - app/xinput
>   - driver/xf86-input-joystick
>   - driver/xf86-input-vmmouse
>   - driver/xf86-video-amdgpu
>   - driver/xf86-video-ati
>   - driver/xf86-video-cirrus
>   - driver/xf86-video-fbdev
>   - driver/xf86-video-freedreno
>   - driver/xf86-video-geode
>   - driver/xf86-video-glint
>   - driver/xf86-video-intel
>   - driver/xf86-video-mach64
>   - driver/xf86-video-omap
>   - driver/xf86-video-qxl
>   - driver/xf86-video-rendition
>   - driver/xf86-video-s3
>   - driver/xf86-video-savage
>   - driver/xf86-video-sis
>   - driver/xf86-video-trident
>   - driver/xf86-video-v4l
>   - driver/xf86-video-vesa
>   - driver/xf86-video-vmware
>   - driver/xf86-video-wsfb
>   - lib/libAppleWM
>   - lib/libxrandrutils
>   - lib/libXt
>   - test/rendercheck (besides, I don't know how to make meson-only releases)
> 
> These I skipped because we don't package them in Solaris and I don't know if
> anyone else still uses them or they should just be archived now:
>   - app/beforelight
>   - app/fdclock
>   - app/mdm
>   - app/rstart
>   - app/scripts
>   - app/xf86dga
>   - app/xfwp
>   - app/xvidtune
>   - app/xcb-demo
>   - driver/xf86-video-ark
>   - driver/xf86-video-armsoc
>   - driver/xf86-video-impact
>   - driver/xf86-video-newport
>   - driver/xf86-video-nested  (has never had a release?)
>   - driver/xf86-video-tga
>   - driver/xf86-video-tseng
>   - driver/xf86-video-xgi
>   - driver/xf86-video-xgixp
>   - lib/libWindowsWM
>   - lib/libXTrap
>   - util/gccmakedep
>   - util/install-check
> 
> (Of those, only xfwpm, xvidtune, & elographics have an entry on
>  release-monitoring.org, which is one sign of use in distros,
>  but not definitive.)
> 
> -- 
>   -Alan Coopersmith-   alan.coopersm...@oracle.com
>Oracle Solaris Engineering - https://blogs.oracle.com/alanc
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___

Re: How do I compile and package the X Server code?

[Peter Hutterer]

On Tue, Feb 12, 2019 at 01:19:51PM -0500, Adam Jackson wrote:
> On Tue, 2019-02-12 at 17:22 +0100, Kevin Brace wrote:
> 
> > I am able to compile X Server, although I do not know at this point
> > how to install it to my preferred location (I will like to install it
> > to /opt for testing purposes).
> 
> https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Default-Prefix.html
> 
> You will probably also want to override PKG_CONFIG_PATH in the
> environment when building drivers against that server. Refer to the
> pkgconfig documentation for details, but it's probably something like:
> 
> $ export 
> PKG_CONFIG_PATH=/opt/xorg/share/pkgconfig:/opt/xorg/lib64/pkgconfig:$PKG_CONFIG_PATH
> 
> That said... in my experience, one of the pleasant features of using a
> distribution is that you can reinstall packages. If I ever really do
> want to test a new buld of Xorg (the only server where the install path
> really matters) I just clobber the existing one, and when I'm done, dnf
> reinstall xorg-x11-server-*.
> 
> > How do I install it to my preferred location and run the compiled
> > version rather than the existing version?
> 
> If you're invoking the X server by hand, just do:
> 
> # /opt/xorg/bin/Xorg
> 
> Convincing your desktop environment's display manager to invoke that
> one instead of the one in /usr/bin depends on the particular display
> manager. (Not wanting to remember how to do this is part of the reason
> I don't use prefixes...)

ftr, I've been installing into /opt/xorg for years, my gdm solution is:
$ mv /usr/bin/Xorg /usr/bin/Xorg_old
$ ln -s /opt/xorg/bin/Xorg /usr/bin/Xorg 

That works but if you use SELinux it may require relabelling and other
magic.

As for the environment, I have this as $HOME/.exportrc.xorg:

export 
PKG_CONFIG_PATH=/opt/xorg/lib/pkgconfig:/opt/xorg/lib64/pkgconfig:/opt/xorg/share/pkgconfig
export LD_LIBRARY_PATH=/opt/xorg/lib/:/opt/xorg/lib64
export PATH=/opt/xorg/bin:$PATH
export ACLOCAL_PATH="/opt/xorg/share/aclocal"
export ACLOCAL="aclocal -I $ACLOCAL_PATH"
export MANPATH=/opt/xorg/share/man/:/usr/share/man

set up an alias to source that file on command and run it before you
you run autotools/meson. The trickiest bit is remembering when --libdir is
needed and when not :)

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xf86-input-synaptics] Use fabs() instead of abs() on double values.

[Peter Hutterer]

On Sun, Feb 10, 2019 at 06:46:12PM +0100, Walter Harms wrote:
> 
> 
> > Matthieu Herrb  hat am 10. Februar 2019 um 17:29
> > geschrieben:
> > 
> > 
> > Silences clang warnings.
> > 
> > Signed-off-by: Matthieu Herrb 
> 
> seems resonable
> Reviewed-by: Walter Harms wharms@bfs,de

remote: remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: remote: I: patch #285313 updated using rev 
a4e5f74b589441077678d5d1546f7de0365a4627.
remote: remote: I: 1 patch(es) updated to state Accepted.
remote: To ssh://kemper.freedesktop.org/git/xorg/driver/xf86-input-synaptics
remote:f8d896d..a4e5f74  a4e5f74b589441077678d5d1546f7de0365a4627 -> master
To ssh://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics
   f8d896d..a4e5f74  master -> master


thanks

Cheers,
   Peter

> > ---
> >  src/synaptics.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/synaptics.c b/src/synaptics.c
> > index 930d02e..bc2d2af 100644
> > --- a/src/synaptics.c
> > +++ b/src/synaptics.c
> > @@ -2602,7 +2602,7 @@ HandleScrolling(SynapticsPrivate * priv, struct
> > SynapticsHwState *hw,
> >  
> >  priv->scroll.delta_y += priv->scroll.coast_speed_y * dtime *
> > abs(para->scroll_dist_vert);
> >  delay = MIN(delay, POLL_MS);
> > -if (abs(priv->scroll.coast_speed_y) < ddy) {
> > +if (fabs(priv->scroll.coast_speed_y) < ddy) {
> >  priv->scroll.coast_speed_y = 0;
> >  priv->scroll.packets_this_scroll = 0;
> >  }
> > @@ -2617,7 +2617,7 @@ HandleScrolling(SynapticsPrivate * priv, struct
> > SynapticsHwState *hw,
> >  double ddx = para->coasting_friction * dtime;
> >  priv->scroll.delta_x += priv->scroll.coast_speed_x * dtime *
> > abs(para->scroll_dist_horiz);
> >  delay = MIN(delay, POLL_MS);
> > -if (abs(priv->scroll.coast_speed_x) < ddx) {
> > +if (fabs(priv->scroll.coast_speed_x) < ddx) {
> >  priv->scroll.coast_speed_x = 0;
> >  priv->scroll.packets_this_scroll = 0;
> >  }
> > @@ -2673,8 +2673,8 @@ clickpad_guess_clickfingers(SynapticsPrivate * priv,
> >   * really, this should be dependent on the touchpad size. Also,
> >   * you'll need to find a touchpad that doesn't lie about it's
> >   * size. Good luck. */
> > -if (abs(x1 - x2) < (priv->maxx - priv->minx) * .3 &&
> > -abs(y1 - y2) < (priv->maxy - priv->miny) * .3) {
> > +if (fabs(x1 - x2) < (priv->maxx - priv->minx) * .3 &&
> > +fabs(y1 - y2) < (priv->maxy - priv->miny) * .3) {
> >  close_point |= (1 << j);
> >  close_point |= (1 << i);
> >  }
> > -- 
> > 2.20.1
> > 
> > ___
> > xorg-devel@lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: https://lists.x.org/mailman/listinfo/xorg-devel
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] XF86keysym: Add XF86XK_RotationLockToggle

[Peter Hutterer]

On Mon, Jan 21, 2019 at 08:23:08PM +0100, Hans de Goede wrote:
> Add XF86XK_RotationLockToggle keysym, to be used as mapping for evdev's
> KEY_ROTATE_LOCK_TOGGLE.
> 
> I've a Point of View P1006W-232 Windows tablet which actually has a
> rotate-lock toggle-button. The latest kernel correctly generates
> KEY_ROTATE_LOCK_TOGGLE events for this. So now I'm hooking up support for
> it through all the higher layers.
> 
> Signed-off-by: Hans de Goede 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  include/X11/XF86keysym.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/X11/XF86keysym.h b/include/X11/XF86keysym.h
> index 9ad8948..dd287e2 100644
> --- a/include/X11/XF86keysym.h
> +++ b/include/X11/XF86keysym.h
> @@ -205,6 +205,8 @@
>  
>  #define XF86XK_AudioPreset   0x1008FFB6   /* Select equalizer preset, e.g. 
> theatre-mode */
>  
> +#define XF86XK_RotationLockToggle 0x1008FFB7 /* Toggle screen rotation lock 
> on/off */
> +
>  /* Keys for special action keys (hot keys) */
>  /* Virtual terminals on some operating systems */
>  #define XF86XK_Switch_VT_1   0x1008FE01
> -- 
> 2.20.1
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xkb_layout documentation

[Peter Hutterer]

On Wed, Jan 02, 2019 at 01:16:22PM +0100, Jens Harms wrote:
> imho both strings "XkbLayout" and "xkb_layout" are ?currently? used. i hope
> i'm using the right repo.

both are currently used, but why we switched from XkbLayout to xkb_layout
evades my memory. Possibly because at some point udev was setting bits here,
but I'm not sure.

> Now i try to checkout what the crazy gnome desktop is doing to my keyboard
> settings, maybe i switch back to fvwm2...

I suggest to tone it down because there's a high chance you will want help
from the people who wrote the code. Throwing words like crazy and annoying
around (doubly so when you're not 100% sure of what the code does) will make
those less likely to help you.

> FYI:
> https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/blob/master/src/kbd.c
> : Line 78
> 
> #endif /* NetBSD */
> "XkbRules", "base",
> "XkbModel", "pc105",
> "XkbLayout", "us",
> NULL
> };

the xorg keyboard driver hasn't been used on linux in a decade or so, you
can safely ignore it.

> https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/blob/master/src/xf86libinput.c
> : Line 1040
> rmlvo.layout = xf86SetStrOption(pInfo->options,
> "xkb_layout",
> defaults.layout);

this loads the defaults from the xserver, overriding it with any XkbLayout
or xkb_layout option found in the config snippets. 

GNOME hasn't used the xorg.conf settings in a long long time now, it will
apply the user-configured layout on login. that layout is stored in
gsettings and will overwrite anything you set in the xorg.conf.

Cheers,
   Peter

> Am Mi., 2. Jan. 2019 um 00:36 Uhr schrieb Peter Hutterer <
> peter.hutte...@who-t.net>:
> 
> > On Wed, Dec 26, 2018 at 11:41:11AM +0100, Jens Harms wrote:
> > > Hi All,
> > > please point me to the current "InputClass" documentatation (if
> > available).
> >
> > should be in man xorg.conf, not sure there's more than that short of
> > google.
> >
> > > I tried to configure my keyboard. because setting the option "XkbLayout"
> > > did not work i was looking at the sources. i did not find any up-to-date
> > > documentation but found anoying uses of XkbLayout and xkb_layout in
> > > libinput. evdev is using  only "xkb_layout".
> >
> > the X server's option parsing code is case-insensitive and ignores
> > underscores. So XkbLayout and xkb_layout are the same option name, which is
> > why the libinput driver only parses the latter. Not sure where you found
> > XkbLayout. git grep shows nothing.
> >
> > Anyway. The drivers only do on-plug xkb option setting, if you have a
> > desktop environment like GNOME it most likely overwrites the xorg.conf
> > settings on login.
> >
> > Cheers,
> >Peter
> >
> >

> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xkb_layout documentation

[Peter Hutterer]

On Wed, Dec 26, 2018 at 11:41:11AM +0100, Jens Harms wrote:
> Hi All,
> please point me to the current "InputClass" documentatation (if available).

should be in man xorg.conf, not sure there's more than that short of google.

> I tried to configure my keyboard. because setting the option "XkbLayout"
> did not work i was looking at the sources. i did not find any up-to-date
> documentation but found anoying uses of XkbLayout and xkb_layout in
> libinput. evdev is using  only "xkb_layout".

the X server's option parsing code is case-insensitive and ignores
underscores. So XkbLayout and xkb_layout are the same option name, which is
why the libinput driver only parses the latter. Not sure where you found
XkbLayout. git grep shows nothing.

Anyway. The drivers only do on-plug xkb option setting, if you have a
desktop environment like GNOME it most likely overwrites the xorg.conf
settings on login.

Cheers,
   Peter

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xorg-driver-xf86-input-libinput and input-keyboard

[Peter Hutterer]

On Wed, Dec 26, 2018 at 11:28:23AM +0100, Jens Harms wrote:
> Hi All,
> xf86libinput.c is initialising "xkb_layout" while kbd.c is using
> "XkbLayout".
> Someone?

see my answer to your other email, xf86nameCompare() in the server ignores
underscores and uppercase so these two are the same option.

Cheers,
   Peter

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH app/xcursorgen v3] Update README for gitlab migration

[Peter Hutterer]

On Mon, Nov 12, 2018 at 11:55:18AM -0800, Alan Coopersmith wrote:
> Signed-off-by: Alan Coopersmith 

Reviewed-by: Peter Hutterer 
> ---
> 
> v2: Moved to README.md and reduced whitespace in front of URLs so that
>  gitlab renders them as links instead of code fragements - see
>  https://gitlab.freedesktop.org/alanc/xcursorgen for formatted view
> Restored link to Submitting Patches page so that we have a place to
>  provide instructions on how we use gitlab.
> Removed GitPage link.
> Changed mailman link from fd.o to x.org URL
> v3: Change remaining http URLs to https
> 
>  README| 25 -
>  README.md | 17 +
>  2 files changed, 17 insertions(+), 25 deletions(-)
>  delete mode 100644 README
>  create mode 100644 README.md
> 
> diff --git a/README b/README
> deleted file mode 100644
> index 6e46f96..000
> --- a/README
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -xcursorgen prepares X11 cursor sets for use with libXcursor.
> -
> -All questions regarding this software should be directed at the
> -Xorg mailing list:
> -
> -http://lists.freedesktop.org/mailman/listinfo/xorg
> -
> -Please submit bug reports to the Xorg bugzilla:
> -
> -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
> -
> -The master development code repository can be found at:
> -
> -git://anongit.freedesktop.org/git/xorg/app/xcursorgen
> -
> -http://cgit.freedesktop.org/xorg/app/xcursorgen
> -
> -For patch submission instructions, see:
> -
> - http://www.x.org/wiki/Development/Documentation/SubmittingPatches
> -
> -For more information on the git code manager, see:
> -
> -http://wiki.x.org/wiki/GitPage
> -
> diff --git a/README.md b/README.md
> new file mode 100644
> index 000..a935f4e
> --- /dev/null
> +++ b/README.md
> @@ -0,0 +1,17 @@
> +xcursorgen prepares X11 cursor sets for use with libXcursor.
> +
> +All questions regarding this software should be directed at the
> +Xorg mailing list:
> +
> +  https://lists.x.org/mailman/listinfo/xorg
> +
> +The master development code repository can be found at:
> +
> +  https://gitlab.freedesktop.org/xorg/app/xcursorgen
> +
> +Please submit bug reports and requests to merge patches there.
> +
> +For patch submission instructions, see:
> +
> +  https://www.x.org/wiki/Development/Documentation/SubmittingPatches
> +
> -- 
> 2.15.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH v3] Allow fd.o to join forces with X.Org

[Peter Hutterer]

On Thu, Nov 08, 2018 at 05:52:08PM -0500, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious to consider extending X.Org's mandate to fd.o.
> 
> Quite a bit of background on fd.o leading up to this has been covered by
> Daniel Stone at XDC 2018 [2] and was covered really well by Jake Edge of
> LWN [1].
> 
> One question that is briefly addressed in the LWN article and was
> thoroughly discussed by members of the X.Org boards, Daniel Stone, and
> others in hallway discussions is the question of whether to extend the
> X.Org membership to projects hosted on fd.o but outside the purpose of
> the X.Org foundation as enacted in its bylaws.
> 
> Most people I talked to would prefer not to dilute X.Org's mission and
> extend membership only to contributors of projects that follow X.Org's
> purpose as enacted in its bylaws. Other projects can continue to be
> hosted on fd.o but won't receive X.Org membership for the mere reason of
> being hosted on fd.o.
> 
> [1] https://lwn.net/Articles/767258/
> [2] https://youtu.be/s22B3E7rUTs
> 
> v3:
>  - Clarify what support of fd.o projects entails without formalizing a
>two-tier system for fd.o projects that fall under X.Org's mandate and
>those who don't
>  - Add link to Daniel's talk at XDC2018
> 
> v2:
>  - Subject line that better describes the intention
>  - Briefly describe reasons behind this change
>  - Drop expanding membership eligibility
> 
> Acked-by: Daniel Stone 
> ---
> 
> We're looking for feedback and comments on this patch. If it's not
> widely controversial the final version of the patch will be put to a
> vote at the 2019 X.Org elections.
> 
> The patch applies to the X.Org bylaws git repo, which can be found at
> https://gitlab.freedesktop.org/xorgfoundation/bylaws
> 
> Happy commenting.

Acked-by: Peter Hutterer 

Cheers,
   Peter

> Harry
> 
>  bylaws.tex | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/bylaws.tex b/bylaws.tex
> index 4ab35a4f7745..5a7542739582 100644
> --- a/bylaws.tex
> +++ b/bylaws.tex
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>  
>   \item Support and educate the general community of users of this
>   graphics stack.
> +
> + \item Support free and open source projects through the freedesktop.org
> + infrastructure. This includes, but is not limited to: Administering and
> + providing project hosting services.
> +
>  \end{enumerate}
>  
>  \article{INTERPRETATION}
> -- 
> 2.19.1
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt] Mark vsprintf_alloc as printf-like function

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
Review this quickly please, we have another release coming up in 9 years
time and I don't want to miss the merge window.

 util.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/util.c b/util.c
index 81c0489..5a23eeb 100644
--- a/util.c
+++ b/util.c
@@ -37,6 +37,7 @@ THE SOFTWARE.
 #include FT_FREETYPE_H
 #include FT_BDF_H
 #include "X11/Xos.h"
+#include "X11/Xfuncproto.h" /* for _X_ATTRIBUTE_PRINTF */
 #include "fonttosfnt.h"
 
 #ifdef NEED_SNPRINTF
@@ -80,6 +81,7 @@ sprintf_alloc(const char *f, ...)
 }
 
 #if HAVE_VASPRINTF
+_X_ATTRIBUTE_PRINTF(1, 0)
 char*
 vsprintf_alloc(const char *f, va_list args)
 {
@@ -92,6 +94,7 @@ vsprintf_alloc(const char *f, va_list args)
 return r;
 }
 #else
+_X_ATTRIBUTE_PRINTF(1, 0)
 char*
 vsprintf_alloc(const char *f, va_list args)
 {
-- 
2.19.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Allow fd.o to join forces with X.Org

[Peter Hutterer]

On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone  wrote:
> >
> > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer  
> > wrote:
> > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > + \item Support free and open source projects through the 
> > > > freedesktop.org
> > > > + infrastructure. For projects outside the scope of item (\ref{1}) 
> > > > support
> > > > + extends to project hosting only.
> > > > +
> > >
> > > Yes to the idea but given that the remaining 11 pages cover all the 
> > > legalese
> > > for xorg I think we need to add at least a section of what "project 
> > > hosting"
> > > means. Even if it's just a "includes but is not limited to blah".  And 
> > > some
> > > addition to 4.1 Powers is needed to spell out what the BoD can do in 
> > > regards
> > > to fdo.
> >
> > Yeah, I think it makes sense. Some things we do:
> >   - provide hosted network services for collaborative development,
> > testing, and discussion, of open-source projects
> >   - administer, improve, and extend this suite of services as necessary
> >   - assist open-source projects in their use of these services
> >   - purchase, lease, or subscribe to, computing and networking
> > infrastructure allowing these services to be run
> 
> I fully agree that we should document all this. I don't think the
> bylaws are the right place though, much better to put that into
> policies that the board approves and which can be adapted as needed.
> Imo bylaws should cover the high-level mission and procedural details,
> as our "constitution", with the really high acceptance criteria of
> 2/3rd of all members approving any changes. Some of the early
> discussions tried to spell out a lot of the fd.o policies in bylaw
> changes, but then we realized it's all there already. All the details
> are much better served in policies enacted by the board, like we do
> with everything else.
> 
> As an example, let's look at XDC. Definitely one of the biggest things
> the foundation does, with handling finances, travel sponsoring grants,
> papers committee, and acquiring lots of sponsors. None of this is
> spelled out in the bylaws, it's all in policies that the board
> deliberates and approves. I think this same approach will also work
> well for fd.o.
> 
> And if members are unhappy with what the board does, they can fix in
> the next election by throwing out the unwanted directors.

yeah, fair call. though IMO in that case we can just reduce to

   \item Support free and open source projects through the freedesktop.org
   infrastructure.

because my gripe is less with the fdo bit but more with defining what
"project hosting" means, given that we use that term to exclude fdo projects
from getting anything else. I think just dropping that bit is sufficient.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC] Allow fd.o to join forces with X.Org

[Peter Hutterer]

On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious to consider extending X.Org's mandate to fd.o.
> 
> Quite a bit of background on fd.o leading up to this has been covered by
> Daniel Stone at XDC 2018 and was covered really well by Jake Edge of LWN [1].
> 
> One question that is briefly addressed in the LWN article and was
> thoroughly discussed by members of the X.Org boards, Daniel Stone, and
> others in hallway discussions is the question of whether to extend the
> X.Org membership to projects hosted on fd.o but outside the purpose of
> the X.Org foundation as enacted in its bylaws.
> 
> Most people I talked to would prefer not to dilute X.Org's mission and
> extend membership only to contributors of projects that follow X.Org's
> purpose as enacted in its bylaws. Other projects can continue to be
> hosted on fd.o but won't receive X.Org membership for the mere reason of
> being hosted on fd.o.
> 
> [1] https://lwn.net/Articles/767258/
> 
> v2:
>  - Subject line that better describes the intention
>  - Briefly describe reasons behind this change
>  - Drop expanding membership eligibility
> ---
> 
> We're looking for feedback and comments on this patch. If it's not
> widely controversial the final version of the patch will be put to a
> vote at the 2019 X.Org elections.
> 
> The patch applies to the X.Org bylaws git repo, which can be found at
> https://gitlab.freedesktop.org/xorgfoundation/bylaws
> 
> Happy commenting.
> 
> Harry
> 
> bylaws.tex | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/bylaws.tex b/bylaws.tex
> index 4ab35a4f7745..44ff4745963b 100644
> --- a/bylaws.tex
> +++ b/bylaws.tex
> @@ -14,7 +14,7 @@ BE IT ENACTED AND IT IS HEREBY ENACTED as a By-law of the 
> X.Org Foundation
>  
>  The purpose of the X.Org Foundation shall be to:
>  \begin{enumerate}[(i)\hspace{.2cm}]
> - \item Research, develop, support, organize, administrate, standardize,
> + \item \label{1} Research, develop, support, organize, administrate, 
> standardize,
>   promote, and defend a free and open accelerated graphics stack. This
>   includes, but is not limited to, the following projects: DRM, Mesa,
>   Wayland and the X Window System,
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>  
>   \item Support and educate the general community of users of this
>   graphics stack.
> +
> + \item Support free and open source projects through the freedesktop.org
> + infrastructure. For projects outside the scope of item (\ref{1}) support
> + extends to project hosting only.
> +

Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah".  And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo. 

Cheers,
   Peter


>  \end{enumerate}
>  
>  \article{INTERPRETATION}
> -- 
> 2.19.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-v4l 4/4] Fix ioctl return value handling

[Peter Hutterer]

Found by coverity

Signed-off-by: Peter Hutterer 
---
 src/v4l.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/src/v4l.c b/src/v4l.c
index 8c2408c..9c6fabe 100644
--- a/src/v4l.c
+++ b/src/v4l.c
@@ -769,12 +769,15 @@ V4lSetPortAttribute(ScrnInfoPtr pScrn,
 } else if (attribute == xvFreq) {
 struct v4l2_frequency   freq;
 memset(, 0, sizeof(freq));
-ioctl(V4L_FD, VIDIOC_G_FREQUENCY, );
-freq.frequency = value;
-if (ioctl(V4L_FD, VIDIOC_S_FREQUENCY, ) == -1)
-xf86Msg(X_ERROR, "v4l: Error %d while setting frequency\n", errno);
-else
-ret = Success;
+if (ioctl(V4L_FD, VIDIOC_G_FREQUENCY, ) == -1) {
+xf86Msg(X_ERROR, "v4l: Error %d while getting frequency\n", errno);
+} else {
+freq.frequency = value;
+if (ioctl(V4L_FD, VIDIOC_S_FREQUENCY, ) == -1)
+xf86Msg(X_ERROR, "v4l: Error %d while setting frequency\n", 
errno);
+else
+ret = Success;
+}
 } else {
 for (i = 0; i < pPPriv->n_qctrl; i++)
 if (pPPriv->XvV4LCtrl[i].xv == attribute)
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-v4l 3/4] Fix handling of realloc failure

[Peter Hutterer]

Coverity complaint and whatnot

Signed-off-by: Peter Hutterer 
---
 src/v4l.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/src/v4l.c b/src/v4l.c
index 583c7b8..8c2408c 100644
--- a/src/v4l.c
+++ b/src/v4l.c
@@ -1120,6 +1120,7 @@ V4LInit(ScrnInfoPtr pScrn, XF86VideoAdaptorPtr **adaptors)
 XF86VideoAdaptorPtr *VAR = NULL;
 char dev[18];
 int  fd,i,j,d;
+void *tmp;
 
 for (i = 0, d = 0; d < MAX_V4L_DEVICES; d++) {
 sprintf(dev, "/dev/video%d", d);
@@ -1164,7 +1165,11 @@ V4LInit(ScrnInfoPtr pScrn, XF86VideoAdaptorPtr 
**adaptors)
 return FALSE;
 
 /* alloc VideoAdaptorRec */
-VAR = realloc(VAR,sizeof(XF86VideoAdaptorPtr)*(i+1));
+tmp = realloc(VAR,sizeof(XF86VideoAdaptorPtr)*(i+1));
+if (!tmp)
+return FALSE;
+VAR = tmp;
+
 VAR[i] = malloc(sizeof(XF86VideoAdaptorRec));
 if (!VAR[i])
 return FALSE;
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-v4l 2/4] Ensure the device name is null-terminated

[Peter Hutterer]

And expand the size to 18, because the stack array we copied this into is 18
bytes long. This covers us for up to 999 (kernel) v4l devices and that is
definitely not a reason to use the "640k ought to be enough" meme.

Found by - you guessed it - coverity!

Signed-off-by: Peter Hutterer 
---
 src/v4l.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/v4l.c b/src/v4l.c
index 0f1058e..583c7b8 100644
--- a/src/v4l.c
+++ b/src/v4l.c
@@ -188,7 +188,7 @@ static const XF86AttributeRec FreqAttr =
 static struct V4L_DEVICE {
 int  fd;
 int  useCount;
-char devName[16];
+char devName[18];
 } v4l_devices[MAX_V4L_DEVICES] = {
 { -1 },
 { -1 },
@@ -1157,7 +1157,8 @@ V4LInit(ScrnInfoPtr pScrn, XF86VideoAdaptorPtr **adaptors)
 }
 
 xf86Msg(X_INFO, "v4l: enabling overlay mode for %s.\n", dev);
-strncpy(V4L_NAME, dev, 16);
+strncpy(V4L_NAME, dev, 18);
+V4L_NAME[17] = '\0';
 V4LBuildEncodings(pPPriv, fd);
 if (NULL == pPPriv->enc)
 return FALSE;
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-video-v4l 1/4] Remove unused variable osname

[Peter Hutterer]

Coverity is unhappy and there's enough unhappiness in this world already, so
let's go for the low-hanging fruit.

Signed-off-by: Peter Hutterer 
---
 src/v4l.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/v4l.c b/src/v4l.c
index 8db8f7d..0f1058e 100644
--- a/src/v4l.c
+++ b/src/v4l.c
@@ -86,7 +86,6 @@ _X_EXPORT XF86ModuleData v4lModuleData = { , 
v4lSetup, NULL };
 static pointer
 v4lSetup(pointer module, pointer opts, int *errmaj, int *errmin)
 {
-const char *osname;
 static Bool setupDone = FALSE;
 
 if (setupDone) {
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libXpm] After fdopen(), use fclose() instead of close() in error path

[Peter Hutterer]

On Sun, Sep 30, 2018 at 03:14:00PM -0700, Alan Coopersmith wrote:
> Found by Oracle's Parfait 2.2 static analyzer:
> 
> Error: File Leak
>File Leak [file-ptr-leak]:
>   Leaked File fp
> at line 94 of lib/libXpm/src/RdFToBuf.c in function 
> 'XpmReadFileToBuffer
> '.
>   fp initialized at line 86 with fdopen
>   fp leaks when len < 0 at line 92.
> 
> Introduced-by: commit 8b3024e6871ce50b34bf2dff924774bd654703bc
> 
> Signed-off-by: Alan Coopersmith 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  src/RdFToBuf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/RdFToBuf.c b/src/RdFToBuf.c
> index 69e3347..1b386f8 100644
> --- a/src/RdFToBuf.c
> +++ b/src/RdFToBuf.c
> @@ -86,15 +86,15 @@ XpmReadFileToBuffer(
>  fp = fdopen(fd, "r");
>  if (!fp) {
>   close(fd);
>   return XpmOpenFailed;
>  }
>  len = stats.st_size;
>  if (len < 0 || len >= SIZE_MAX) {
> - close(fd);
> + fclose(fp);
>   return XpmOpenFailed;
>  }
>  ptr = (char *) XpmMalloc(len + 1);
>  if (!ptr) {
>   fclose(fp);
>   return XpmNoMemory;
>  }
> -- 
> 2.15.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH app/xcursorgen] Update README for gitlab migration

[Peter Hutterer]

On Mon, Oct 01, 2018 at 10:11:07AM -0700, Alan Coopersmith wrote:
> Does anyone have feedback on changing our README's like this?   While I
> sent this out as a patch to a specific repo, I figured once we have
> an agreed upon template, we'd apply it to all of the repos.

oh well, if you ask... :)

> On 09/22/18 12:11 PM, Alan Coopersmith wrote:
> > Signed-off-by: Alan Coopersmith 
> > ---
> >   README | 12 ++--
> >   1 file changed, 2 insertions(+), 10 deletions(-)
> > 
> > diff --git a/README b/README
> > index 6e46f96..f830ada 100644
> > --- a/README
> > +++ b/README
> > @@ -1,25 +1,17 @@
> >   xcursorgen prepares X11 cursor sets for use with libXcursor.
> >   All questions regarding this software should be directed at the
> >   Xorg mailing list:
> >   http://lists.freedesktop.org/mailman/listinfo/xorg
> > -Please submit bug reports to the Xorg bugzilla:
> > -
> > -https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
> > -
> >   The master development code repository can be found at:
> > -git://anongit.freedesktop.org/git/xorg/app/xcursorgen
> > -
> > -http://cgit.freedesktop.org/xorg/app/xcursorgen
> > -
> > -For patch submission instructions, see:
> > +https://gitlab.freedesktop.org/xorg/app/xcursorgen
> > -   http://www.x.org/wiki/Development/Documentation/SubmittingPatches

IMO we (i.e. not me but someone else) should update that URL for the
glorious gitlab-enabled present and leave it in the README


> > +Please submit bug reports and requests to merge patches there.
> >   For more information on the git code manager, see:
> >   http://wiki.x.org/wiki/GitPage

this link needs to go and possibly merged into the SubmittingPatches page
(which could be renamed, because why not) 

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/xrandr] init the name to 0

[Peter Hutterer]

There are a few conditions where coverity finds a use of an uninitialized
field of the name_t struct. These are rather messy combinations of conditions,
so let's go with the simple solution here and just init everything to 0.
This may still have side-effects but at least they'll be more obvious than the
previous "use whatever memory is leftover from breakfast".

This patch also adds a missing init_name(), much for the same reason.

Signed-off-by: Peter Hutterer 
---
 xrandr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/xrandr.c b/xrandr.c
index 7f1e867..ce3cd91 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -637,6 +637,7 @@ print_verbose_mode (const XRRModeInfo *mode, Bool current, 
Bool preferred)
 static void
 init_name (name_t *name)
 {
+memset(name, 0, sizeof(*name));
 name->kind = name_none;
 }
 
@@ -1822,6 +1823,7 @@ get_outputs (void)
output_t*output;
name_t  output_name;
if (!output_info) fatal ("could not get output 0x%lx information\n", 
res->outputs[o]);
+   init_name(_name);
set_name_xid (_name, res->outputs[o]);
set_name_index (_name, o);
set_name_string (_name, output_info->name);
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH app/sessreg] Replace strncpy calls with a sane version that always terminates

[Peter Hutterer]

On Wed, Sep 12, 2018 at 09:09:22AM +0200, Walter Harms wrote:
> 
> 
> > Peter Hutterer  hat am 12. September 2018 um 06:50
> > geschrieben:
> > 
> > 
> > Fixes coverity complaints about potentially unterminated strings
> > 
> > Signed-off-by: Peter Hutterer 
> > ---
> >  sessreg.c | 26 +-
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/sessreg.c b/sessreg.c
> > index 0a8fdb2..53b30b0 100644
> > --- a/sessreg.c
> > +++ b/sessreg.c
> > @@ -192,6 +192,14 @@ sysnerr (int x, const char *s)
> > return x;
> >  }
> >  
> > +static void
> > +safe_strncpy(char *dest, const char *src, size_t n)
> > +{
> 
> if you add
>  if (!src)
>   return;
> 
> you can also remove the if (x) before strncpy()

tbh, I'd rather touch this code as little as possible. there's more cleanup
possible but...

Cheers,
   Peter

> 
> > +(void)strncpy(dest, src, n);
> > +if (n > 0)
> > +dest[n - 1] = '\0';
> > +}
> > +
> 
> 
> just my 2 cents
> 
> re,
>  wh
> 
> >  int
> >  main (int argc, char **argv)
> >  {
> > @@ -406,9 +414,9 @@ main (int argc, char **argv)
> > memset(, 0, sizeof(ll));
> > ll.ll_time = current_time;
> > if (line)
> > -(void) strncpy (ll.ll_line, line, sizeof (ll.ll_line));
> > +safe_strncpy (ll.ll_line, line, sizeof (ll.ll_line));
> > if (host_name)
> > -(void) strncpy (ll.ll_host, host_name, sizeof 
> > (ll.ll_host));
> > +safe_strncpy (ll.ll_host, host_name, sizeof 
> > (ll.ll_host));
> >  
> > sysnerr (write (llog, (char *) , sizeof (ll))
> > == sizeof (ll), "write lastlog entry");
> > @@ -429,11 +437,11 @@ set_utmp (struct utmp *u, char *line, char *user, char
> > *host, time_t date, int a
> >  {
> > memset (u, 0, sizeof (*u));
> > if (line)
> > -   (void) strncpy (u->ut_line, line, sizeof (u->ut_line));
> > +   safe_strncpy (u->ut_line, line, sizeof (u->ut_line));
> > else
> > memset (u->ut_line, 0, sizeof (u->ut_line));
> > if (addp && user)
> > -   (void) strncpy (u->ut_name, user, sizeof (u->ut_name));
> > +   safe_strncpy (u->ut_name, user, sizeof (u->ut_name));
> > else
> > memset (u->ut_name, 0, sizeof (u->ut_name));
> >  #ifdef HAVE_STRUCT_UTMP_UT_ID
> > @@ -451,7 +459,7 @@ set_utmp (struct utmp *u, char *line, char *user, char
> > *host, time_t date, int a
> > i -= sizeof (u->ut_id);
> > else
> > i = 0;
> > -   (void) strncpy (u->ut_id, line + i, sizeof (u->ut_id));
> > +   safe_strncpy (u->ut_id, line + i, sizeof (u->ut_id));
> > } else
> > memset (u->ut_id, 0, sizeof (u->ut_id));
> >  #endif
> > @@ -469,7 +477,7 @@ set_utmp (struct utmp *u, char *line, char *user, char
> > *host, time_t date, int a
> >  #endif
> >  #ifdef HAVE_STRUCT_UTMP_UT_HOST
> > if (addp && host)
> > -   (void) strncpy (u->ut_host, host, sizeof (u->ut_host));
> > +   safe_strncpy (u->ut_host, host, sizeof (u->ut_host));
> > else
> > memset (u->ut_host, 0, sizeof (u->ut_host));
> >  #endif
> > @@ -513,7 +521,7 @@ set_utmpx (struct utmpx *u, const char *line, const char
> > *user,
> > if(strcmp(line, ":0") == 0)
> > (void) strcpy(u->ut_line, "console");
> > else
> > -   (void) strncpy (u->ut_line, line, sizeof (u->ut_line));
> > +   safe_strncpy (u->ut_line, line, sizeof (u->ut_line));
> >  
> > strncpy(u->ut_host, line, sizeof(u->ut_host));
> >  #ifdef HAVE_STRUCT_UTMPX_UT_SYSLEN
> > @@ -523,7 +531,7 @@ set_utmpx (struct utmpx *u, const char *line, const char
> > *user,
> > else
> > memset (u->ut_line, 0, sizeof (u->ut_line));
> > if (addp && user)
> > -   (void) strncpy (u->ut_user, user, sizeof (u->ut_user));
> > +   safe_strncpy (u->ut_user, user, sizeof (u->ut_user));
> > else
> > memset (u->ut_user, 0, sizeof

[PATCH xinput] property: plug a memory leak

[Peter Hutterer]

Not that it matters since we'll exit after this call anyway, but coverity is
unhappy and that makes us all unhappy, doesn't it?

Signed-off-by: Peter Hutterer 
---
 src/property.c | 27 +++
 1 file changed, 15 insertions(+), 12 deletions(-)

diff --git a/src/property.c b/src/property.c
index e4a46f8..071f80f 100644
--- a/src/property.c
+++ b/src/property.c
@@ -610,19 +610,20 @@ do_set_prop_xi2(Display *dpy, Atom type, int format, int 
argc, char **argv, char
 unsigned char *c;
 int16_t *s;
 int32_t *l;
-} data;
+} data = { NULL };
+int rc = EXIT_FAILURE;
 
 if (argc < 3)
 {
 fprintf(stderr, "Usage: xinput %s %s\n", n, desc);
-return EXIT_FAILURE;
+goto out;
 }
 
 info = xi2_find_device_info(dpy, argv[0]);
 if (!info)
 {
 fprintf(stderr, "unable to find device %s\n", argv[0]);
-return EXIT_FAILURE;
+goto out;
 }
 
 name = argv[1];
@@ -631,7 +632,7 @@ do_set_prop_xi2(Display *dpy, Atom type, int format, int 
argc, char **argv, char
 
 if (prop == None) {
 fprintf(stderr, "invalid property '%s'\n", name);
-return EXIT_FAILURE;
+goto out;
 }
 
 float_atom = XInternAtom(dpy, "FLOAT", False);
@@ -643,7 +644,7 @@ do_set_prop_xi2(Display *dpy, Atom type, int format, int 
argc, char **argv, char
   _after, ) != Success) {
 fprintf(stderr, "failed to get property type and format for 
'%s'\n",
 name);
-return EXIT_FAILURE;
+goto out;
 } else {
 if (type == None)
 type = old_type;
@@ -657,7 +658,7 @@ do_set_prop_xi2(Display *dpy, Atom type, int format, int 
argc, char **argv, char
 if (type == None) {
 fprintf(stderr, "property '%s' doesn't exist, you need to specify "
 "its type and format\n", name);
-return EXIT_FAILURE;
+goto out;
 }
 
 data.c = calloc(nelements, sizeof(int32_t));
@@ -678,36 +679,38 @@ do_set_prop_xi2(Display *dpy, Atom type, int format, int 
argc, char **argv, char
 break;
 default:
 fprintf(stderr, "unexpected size for property %s", name);
-return EXIT_FAILURE;
+goto out;
 }
 } else if (type == float_atom) {
 if (format != 32) {
 fprintf(stderr, "unexpected format %d for property '%s'\n",
 format, name);
-return EXIT_FAILURE;
+goto out;
 }
 *(float *)(data.l + i) = strtod(argv[2 + i], );
 if (endptr == argv[2 + i]) {
 fprintf(stderr, "argument %s could not be parsed\n", argv[2 + 
i]);
-return EXIT_FAILURE;
+goto out;
 }
 } else if (type == XA_ATOM) {
 if (format != 32) {
 fprintf(stderr, "unexpected format %d for property '%s'\n",
 format, name);
-return EXIT_FAILURE;
+goto out;
 }
 data.l[i] = parse_atom(dpy, argv[2 + i]);
 } else {
 fprintf(stderr, "unexpected type for property '%s'\n", name);
-return EXIT_FAILURE;
+goto out;
 }
 }
 
 XIChangeProperty(dpy, info->deviceid, prop, type, format, PropModeReplace,
   data.c, nelements);
+rc = EXIT_SUCCESS;
+out:
 free(data.c);
-return EXIT_SUCCESS;
+return rc;
 }
 #endif
 
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/sessreg] Replace strncpy calls with a sane version that always terminates

[Peter Hutterer]

Fixes coverity complaints about potentially unterminated strings

Signed-off-by: Peter Hutterer 
---
 sessreg.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/sessreg.c b/sessreg.c
index 0a8fdb2..53b30b0 100644
--- a/sessreg.c
+++ b/sessreg.c
@@ -192,6 +192,14 @@ sysnerr (int x, const char *s)
return x;
 }
 
+static void
+safe_strncpy(char *dest, const char *src, size_t n)
+{
+(void)strncpy(dest, src, n);
+if (n > 0)
+dest[n - 1] = '\0';
+}
+
 int
 main (int argc, char **argv)
 {
@@ -406,9 +414,9 @@ main (int argc, char **argv)
memset(, 0, sizeof(ll));
ll.ll_time = current_time;
if (line)
-(void) strncpy (ll.ll_line, line, sizeof (ll.ll_line));
+safe_strncpy (ll.ll_line, line, sizeof (ll.ll_line));
if (host_name)
-(void) strncpy (ll.ll_host, host_name, sizeof 
(ll.ll_host));
+safe_strncpy (ll.ll_host, host_name, sizeof 
(ll.ll_host));
 
sysnerr (write (llog, (char *) , sizeof (ll))
== sizeof (ll), "write lastlog entry");
@@ -429,11 +437,11 @@ set_utmp (struct utmp *u, char *line, char *user, char 
*host, time_t date, int a
 {
memset (u, 0, sizeof (*u));
if (line)
-   (void) strncpy (u->ut_line, line, sizeof (u->ut_line));
+   safe_strncpy (u->ut_line, line, sizeof (u->ut_line));
else
memset (u->ut_line, 0, sizeof (u->ut_line));
if (addp && user)
-   (void) strncpy (u->ut_name, user, sizeof (u->ut_name));
+   safe_strncpy (u->ut_name, user, sizeof (u->ut_name));
else
memset (u->ut_name, 0, sizeof (u->ut_name));
 #ifdef HAVE_STRUCT_UTMP_UT_ID
@@ -451,7 +459,7 @@ set_utmp (struct utmp *u, char *line, char *user, char 
*host, time_t date, int a
i -= sizeof (u->ut_id);
else
i = 0;
-   (void) strncpy (u->ut_id, line + i, sizeof (u->ut_id));
+   safe_strncpy (u->ut_id, line + i, sizeof (u->ut_id));
} else
memset (u->ut_id, 0, sizeof (u->ut_id));
 #endif
@@ -469,7 +477,7 @@ set_utmp (struct utmp *u, char *line, char *user, char 
*host, time_t date, int a
 #endif
 #ifdef HAVE_STRUCT_UTMP_UT_HOST
if (addp && host)
-   (void) strncpy (u->ut_host, host, sizeof (u->ut_host));
+   safe_strncpy (u->ut_host, host, sizeof (u->ut_host));
else
memset (u->ut_host, 0, sizeof (u->ut_host));
 #endif
@@ -513,7 +521,7 @@ set_utmpx (struct utmpx *u, const char *line, const char 
*user,
if(strcmp(line, ":0") == 0)
(void) strcpy(u->ut_line, "console");
else
-   (void) strncpy (u->ut_line, line, sizeof (u->ut_line));
+   safe_strncpy (u->ut_line, line, sizeof (u->ut_line));
 
strncpy(u->ut_host, line, sizeof(u->ut_host));
 #ifdef HAVE_STRUCT_UTMPX_UT_SYSLEN
@@ -523,7 +531,7 @@ set_utmpx (struct utmpx *u, const char *line, const char 
*user,
else
memset (u->ut_line, 0, sizeof (u->ut_line));
if (addp && user)
-   (void) strncpy (u->ut_user, user, sizeof (u->ut_user));
+   safe_strncpy (u->ut_user, user, sizeof (u->ut_user));
else
memset (u->ut_user, 0, sizeof (u->ut_user));
 
@@ -541,7 +549,7 @@ set_utmpx (struct utmpx *u, const char *line, const char 
*user,
i -= sizeof (u->ut_id);
else
i = 0;
-   (void) strncpy (u->ut_id, line + i, sizeof (u->ut_id));
+   safe_strncpy (u->ut_id, line + i, sizeof (u->ut_id));
 
/* make sure there is no entry using identical ut_id */
if (!UtmpxIdOpen(u->ut_id) && addp) {
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] devices: break after finding and removing device from lists

[Peter Hutterer]

On Wed, Sep 12, 2018 at 11:40:56AM +1000, Dave Airlie wrote:
> From: Dave Airlie 
> 
> Coverity complains about a use after free in here after the
> freeing, I can't follow the linked list so well, but whot
> says the device can only be on one list once, so break should
> fix it.
> 
> Signed-off-by: Dave Airlie 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  dix/devices.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/dix/devices.c b/dix/devices.c
> index 4a628afb0..1b18b168e 100644
> --- a/dix/devices.c
> +++ b/dix/devices.c
> @@ -1177,6 +1177,7 @@ RemoveDevice(DeviceIntPtr dev, BOOL sendevent)
>  flags[tmp->id] = IsMaster(tmp) ? XIMasterRemoved : 
> XISlaveRemoved;
>  CloseDevice(tmp);
>  ret = Success;
> +break;
>  }
>  }
>  
> @@ -1193,6 +1194,7 @@ RemoveDevice(DeviceIntPtr dev, BOOL sendevent)
>  prev->next = next;
>  
>  ret = Success;
> +break;
>  }
>  }
>  
> -- 
> 2.17.1
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] hw/xwin: Fix 'make distcheck'

[Peter Hutterer]

On Mon, Aug 27, 2018 at 12:41:22PM +0100, Jon Turney wrote:
> Add internal.h to SOURCES, omitted from 126c1cfa
> 
> Signed-off-by: Jon Turney 

   cd285922c..a9a5bd002  master -> master

Cheers,
   Peter

> ---
>  hw/xwin/winclipboard/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/hw/xwin/winclipboard/Makefile.am 
> b/hw/xwin/winclipboard/Makefile.am
> index a1079aec6..bfd302413 100644
> --- a/hw/xwin/winclipboard/Makefile.am
> +++ b/hw/xwin/winclipboard/Makefile.am
> @@ -1,6 +1,7 @@
>  noinst_LTLIBRARIES = libXWinclipboard.la
>  
>  libXWinclipboard_la_SOURCES = \
> + internal.h \
>   winclipboard.h \
>   textconv.c \
>   thread.c \
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: use wayland axis_discrete event

[Peter Hutterer]

On Wed, Aug 15, 2018 at 08:54:25PM +1200, Scott Anderson wrote:
> On 6/08/18 6:09 PM, Scott Anderson wrote:
> > This prevents multiple scroll events happening for wayland compositors
> > which send axis values other than 10. For example, libinput will
> > typically return 15 for each scroll wheel step, and if a wayland
> > compositor sends those to xwayland without normalising them, 2 scroll
> > wheel steps will end up as 3 xorg scroll events. By listening for the
> > discrete_axis event, this will now correctly send only 2 xorg scroll
> > events.
> > 
> > The wayland protocol gurantees that there will always be an axis event
> > following an axis_discrete event. However, it does not gurantee that
> > other events (including other axis_discrete+axis pairs) will not happen
> > in between them. So we must keep a list of outstanding axis_discrete
> > events.
> > 
> > Signed-off-by: Scott Anderson 
> > ---
> >   hw/xwayland/xwayland-input.c | 41 +++-
> >   hw/xwayland/xwayland.h   |  1 +
> >   2 files changed, 41 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> > index a602f0887..6fd3c416b 100644
> > --- a/hw/xwayland/xwayland-input.c
> > +++ b/hw/xwayland/xwayland-input.c
> > @@ -37,6 +37,12 @@
> >   #include 
> >   #include "tablet-unstable-v2-client-protocol.h"
> > +struct axis_discrete_pending {
> > +struct xorg_list l;
> > +uint32_t axis;
> > +int32_t discrete;
> > +};
> > +
> >   struct sync_pending {
> >   struct xorg_list l;
> >   DeviceIntPtr pending_dev;
> > @@ -565,6 +571,8 @@ pointer_handle_axis(void *data, struct wl_pointer 
> > *pointer,
> >   int index;
> >   const int divisor = 10;
> >   ValuatorMask mask;
> > +struct axis_discrete_pending *pending = NULL;
> > +struct axis_discrete_pending *iter;
> >   switch (axis) {
> >   case WL_POINTER_AXIS_VERTICAL_SCROLL:
> > @@ -577,8 +585,22 @@ pointer_handle_axis(void *data, struct wl_pointer 
> > *pointer,
> >   return;
> >   }
> > +xorg_list_for_each_entry(iter, _seat->axis_discrete_pending, l) {
> > +if (iter->axis == axis) {
> > +pending = iter;
> > +break;
> > +}
> > +}
> > +
> >   valuator_mask_zero();
> > -valuator_mask_set_double(, index, wl_fixed_to_double(value) / 
> > divisor);
> > +
> > +if (pending) {
> > +valuator_mask_set(, index, pending->discrete);
> > +xorg_list_del(>l);
> > +free(pending);
> > +} else {
> > +valuator_mask_set_double(, index, wl_fixed_to_double(value) / 
> > divisor);
> > +}
> >   QueuePointerEvents(xwl_seat->pointer, MotionNotify, 0, 
> > POINTER_RELATIVE, );
> >   }
> > @@ -608,6 +630,16 @@ static void
> >   pointer_handle_axis_discrete(void *data, struct wl_pointer *wl_pointer,
> >uint32_t axis, int32_t discrete)
> >   {
> > +struct xwl_seat *xwl_seat = data;
> > +
> > +struct axis_discrete_pending *pending = malloc(sizeof *pending);
> > +if (!pending)
> > +return;
> > +
> > +pending->axis = axis;
> > +pending->discrete = discrete;
> > +
> > +xorg_list_add(>l, _seat->axis_discrete_pending);
> >   }
> >   static const struct wl_pointer_listener pointer_listener = {
> > @@ -1337,6 +1369,7 @@ create_input_device(struct xwl_screen *xwl_screen, 
> > uint32_t id, uint32_t version
> >   wl_array_init(_seat->keys);
> >   xorg_list_init(_seat->touches);
> > +xorg_list_init(_seat->axis_discrete_pending);
> >   xorg_list_init(_seat->sync_pending);
> >   }
> > @@ -1345,6 +1378,7 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
> >   {
> >   struct xwl_touch *xwl_touch, *next_xwl_touch;
> >   struct sync_pending *p, *npd;
> > +struct axis_discrete_pending *ad, *ad_next;
> >   xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
> > _seat->touches, link_touch) {
> > @@ -1357,6 +1391,11 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
> >   free (p);
> >   }
> > +xorg_list_for_each_entry_safe(ad, ad_next, 
> > _seat->axis_discrete_pending, l) {
> > +xorg_list_del(>l);
> > +free(ad);
> > +}
> > +
> >   release_tablet_manager_seat(xwl_seat);
> >   release_grab(xwl_seat);
> > diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> > index d70ad54bf..1a6e2f380 100644
> > --- a/hw/xwayland/xwayland.h
> > +++ b/hw/xwayland/xwayland.h
> > @@ -272,6 +272,7 @@ struct xwl_seat {
> >   char *keymap;
> >   struct wl_surface *keyboard_focus;
> > +struct xorg_list axis_discrete_pending;
> >   struct xorg_list sync_pending;
> >   struct xwl_pointer_warp_emulator *pointer_warp_emulator;
> > 
> 
> Ping.

sorry, this is pushed now.

   f79e53685..cd285922c  master -> master

Cheers,
   Peter

___
xorg-devel@lists.x.org: X.Org development

Re: [PATCH xserver] man: Mention that InputClass overrides InputDevice.

[Peter Hutterer]

On Tue, Aug 21, 2018 at 10:02:14AM +0200, Michal Srb wrote:
> To prevent confusion, since user may consider InputDevice as "stronger
> selector" and expect that it will take priority over InputClass.

I don't think this is correct, because the two are completely different.
InputClass will pick up any udev-added device it matches on. InputDevice
will just apply to that one device, with the side-effect that if you don't
exclude that explicit device from the InputClass section, you'll get a
duplicate device.

This is the case in the bug you linked:

 [11.068] (II) XINPUT: Adding extended input device "Touchpad" (type: 
TOUCHPAD, id 6)
 [11.372] (II) XINPUT: Adding extended input device "SynPS/2 Synaptics 
TouchPad" (type: TOUCHPAD, id 14)

xinput list should show both devices and general behaviour is going to be
odd because all events are now sent from both devices simultaneously. So
each click is a double-click, etc.

This all works with evdev because it has duplicate detection and refuses to
add the InputClass device (which always comes after the InputDevice due to
how the server works). synaptics doesn't have that because historically it
didn't need to. the libinput driver doesn't have that duplicate detection
either.

So nak to this patch, we'll need some more detail explaining this in the man
page. As the most simple general rule though: don't mix InputDevice and
InputClass.

Cheers,
   Peter

> ---
> Downstream reference:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1105311
> 
>  hw/xfree86/man/xorg.conf.man | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man
> index 958926243..c921a1487 100644
> --- a/hw/xfree86/man/xorg.conf.man
> +++ b/hw/xfree86/man/xorg.conf.man
> @@ -892,6 +892,10 @@ sections recognise some driver\-independent
>  which are described here.
>  See the individual input driver manual pages for a description of the
>  device\-specific options.
> +.B InputClass
> +sections which match this device will override the options specified in
> +.B InputDevice
> +section.
>  .TP 7
>  .BI "Option \*qAutoServerLayout\*q  \*q" boolean \*q
>  Always add the device to the ServerLayout section used by this instance of
> @@ -1022,7 +1026,11 @@ class of input devices as they are automatically 
> added. An input device can
>  match more than one
>  .B InputClass
>  section. Each class can override settings from a previous class, so it is
> -best to arrange the sections with the most generic matches first.
> +best to arrange the sections with the most generic matches first. Options in
> +.B InputClass
> +sections override options from the device's backend, including those set in
> +.B InputDevice
> +section.
>  .PP
>  .B InputClass
>  sections have the following format:
> -- 
> 2.16.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: use wayland axis_discrete event

[Peter Hutterer]

On Mon, Aug 06, 2018 at 06:09:26PM +1200, Scott Anderson wrote:
> This prevents multiple scroll events happening for wayland compositors
> which send axis values other than 10. For example, libinput will
> typically return 15 for each scroll wheel step, and if a wayland
> compositor sends those to xwayland without normalising them, 2 scroll
> wheel steps will end up as 3 xorg scroll events. By listening for the
> discrete_axis event, this will now correctly send only 2 xorg scroll
> events.
> 
> The wayland protocol gurantees that there will always be an axis event
> following an axis_discrete event. However, it does not gurantee that
> other events (including other axis_discrete+axis pairs) will not happen
> in between them. So we must keep a list of outstanding axis_discrete
> events.
> 
> Signed-off-by: Scott Anderson 

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  hw/xwayland/xwayland-input.c | 41 +++-
>  hw/xwayland/xwayland.h   |  1 +
>  2 files changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index a602f0887..6fd3c416b 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -37,6 +37,12 @@
>  #include 
>  #include "tablet-unstable-v2-client-protocol.h"
>  
> +struct axis_discrete_pending {
> +struct xorg_list l;
> +uint32_t axis;
> +int32_t discrete;
> +};
> +
>  struct sync_pending {
>  struct xorg_list l;
>  DeviceIntPtr pending_dev;
> @@ -565,6 +571,8 @@ pointer_handle_axis(void *data, struct wl_pointer 
> *pointer,
>  int index;
>  const int divisor = 10;
>  ValuatorMask mask;
> +struct axis_discrete_pending *pending = NULL;
> +struct axis_discrete_pending *iter;
>  
>  switch (axis) {
>  case WL_POINTER_AXIS_VERTICAL_SCROLL:
> @@ -577,8 +585,22 @@ pointer_handle_axis(void *data, struct wl_pointer 
> *pointer,
>  return;
>  }
>  
> +xorg_list_for_each_entry(iter, _seat->axis_discrete_pending, l) {
> +if (iter->axis == axis) {
> +pending = iter;
> +break;
> +}
> +}
> +
>  valuator_mask_zero();
> -valuator_mask_set_double(, index, wl_fixed_to_double(value) / 
> divisor);
> +
> +if (pending) {
> +valuator_mask_set(, index, pending->discrete);
> +xorg_list_del(>l);
> +free(pending);
> +} else {
> +valuator_mask_set_double(, index, wl_fixed_to_double(value) / 
> divisor);
> +}
>  QueuePointerEvents(xwl_seat->pointer, MotionNotify, 0, POINTER_RELATIVE, 
> );
>  }
>  
> @@ -608,6 +630,16 @@ static void
>  pointer_handle_axis_discrete(void *data, struct wl_pointer *wl_pointer,
>   uint32_t axis, int32_t discrete)
>  {
> +struct xwl_seat *xwl_seat = data;
> +
> +struct axis_discrete_pending *pending = malloc(sizeof *pending);
> +if (!pending)
> +return;
> +
> +pending->axis = axis;
> +pending->discrete = discrete;
> +
> +xorg_list_add(>l, _seat->axis_discrete_pending);
>  }
>  
>  static const struct wl_pointer_listener pointer_listener = {
> @@ -1337,6 +1369,7 @@ create_input_device(struct xwl_screen *xwl_screen, 
> uint32_t id, uint32_t version
>  wl_array_init(_seat->keys);
>  
>  xorg_list_init(_seat->touches);
> +xorg_list_init(_seat->axis_discrete_pending);
>  xorg_list_init(_seat->sync_pending);
>  }
>  
> @@ -1345,6 +1378,7 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
>  {
>  struct xwl_touch *xwl_touch, *next_xwl_touch;
>  struct sync_pending *p, *npd;
> +struct axis_discrete_pending *ad, *ad_next;
>  
>  xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
>_seat->touches, link_touch) {
> @@ -1357,6 +1391,11 @@ xwl_seat_destroy(struct xwl_seat *xwl_seat)
>  free (p);
>  }
>  
> +xorg_list_for_each_entry_safe(ad, ad_next, 
> _seat->axis_discrete_pending, l) {
> +xorg_list_del(>l);
> +free(ad);
> +}
> +
>  release_tablet_manager_seat(xwl_seat);
>  
>  release_grab(xwl_seat);
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index d70ad54bf..1a6e2f380 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -272,6 +272,7 @@ struct xwl_seat {
>  char *keymap;
>  struct wl_surface *keyboard_focus;
>  
> +struct xorg_list axis_discrete_pending;
>  struct xorg_list sync_pending;
>  
>  struct xwl_pointer_warp_emulator *pointer_warp_emulator;
> -- 
> 2.18.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] meson: Add an option to build XSELINUX.

[Peter Hutterer]

On Thu, Aug 09, 2018 at 08:05:05PM -0700, Eric Anholt wrote:
> Peter Hutterer  writes:
> 
> > On Thu, Aug 09, 2018 at 01:02:41PM -0700, Eric Anholt wrote:
> >> Dependencies are ported from the automake build.
> >> 
> >> v2: Make it a tristate defaulting to 'auto'.  Use pkg-config for libaudit.
> >> 
> >> Signed-off-by: Eric Anholt 
> >> ---
> >>  meson.build   | 20 +---
> >>  meson_options.txt |  2 ++
> >>  2 files changed, 19 insertions(+), 3 deletions(-)
> >> 
> >> diff --git a/meson.build b/meson.build
> >> index e7ce68a502c3..53cdbe2beb3d 100644
> >> --- a/meson.build
> >> +++ b/meson.build
> >> @@ -442,9 +442,6 @@ elif get_option('mitshm') == 'true'
> >>  build_mitshm = true
> >>  endif
> >>  
> >> -# XXX: Allow configuration of these.
> >> -build_xselinux = false
> >> -
> >>  m_dep = cc.find_library('m', required : false)
> >>  dl_dep = cc.find_library('dl', required : false)
> >>  
> >> @@ -506,6 +503,23 @@ inc = include_directories(
> >>  'xfixes',
> >>  )
> >>  
> >> +build_xselinux = false
> >> +if get_option('xselinux') != 'false'
> >> +dep_selinux = dependency('libselinux', version: '>= 2.0.86',
> >> +   required: get_option('xselinux') == 'true')
> >> +dep_audit = dependency('audit', required: get_option('xselinux') == 
> >> 'true')
> >> +if get_option('xselinux') == 'true'
> >> +build_xselinux = true
> >> +else
> >
> > you don't need the if here, if option(xselinux) is true, both deps will
> > are required and cannot be anything but found() == true.
> >
> > but either way, Reviewed-by: Peter Hutterer 
> 
> I'm trying to make sure that build_xselinux is never set if the tristate
> is set to false, but that we auto-select if we're in auto mode.

sure, but this (hand-written) diff should give you the same result:

+build_xselinux = false
+if get_option('xselinux') != 'false'
+dep_selinux = dependency('libselinux', version: '>= 2.0.86',
+required: get_option('xselinux') == 'true')
+dep_audit = dependency('audit', required: get_option('xselinux') == 'true')
+build_xselinux = dep_selinux.found() and dep_audit.found()
+
+if build_xselinux
+common_dep += dep_selinux
+common_dep += dep_audit
+endif
+endif

if xselinux is false, you never enter this anyway
if xselinux is true, you either have both libs or fail earlier, so found() and
found() is always true
if xselinux is auto, found() and found() decides whether to build it

arguably the second "if build_xselinux" isn't required either because
dep_selinux/dep_audit are valid dependency objects even if not found. but I
guess we don't want to add one if the other one doesn't exist.

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] meson: Add an option to build XSELINUX.

[Peter Hutterer]

On Thu, Aug 09, 2018 at 01:02:41PM -0700, Eric Anholt wrote:
> Dependencies are ported from the automake build.
> 
> v2: Make it a tristate defaulting to 'auto'.  Use pkg-config for libaudit.
> 
> Signed-off-by: Eric Anholt 
> ---
>  meson.build   | 20 +---
>  meson_options.txt |  2 ++
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index e7ce68a502c3..53cdbe2beb3d 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -442,9 +442,6 @@ elif get_option('mitshm') == 'true'
>  build_mitshm = true
>  endif
>  
> -# XXX: Allow configuration of these.
> -build_xselinux = false
> -
>  m_dep = cc.find_library('m', required : false)
>  dl_dep = cc.find_library('dl', required : false)
>  
> @@ -506,6 +503,23 @@ inc = include_directories(
>  'xfixes',
>  )
>  
> +build_xselinux = false
> +if get_option('xselinux') != 'false'
> +dep_selinux = dependency('libselinux', version: '>= 2.0.86',
> +  required: get_option('xselinux') == 'true')
> +dep_audit = dependency('audit', required: get_option('xselinux') == 
> 'true')
> +if get_option('xselinux') == 'true'
> +build_xselinux = true
> +else

you don't need the if here, if option(xselinux) is true, both deps will
are required and cannot be anything but found() == true.

but either way, Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> +build_xselinux = dep_selinux.found() and dep_audit.found()
> +endif
> +
> +if build_xselinux
> +common_dep += dep_selinux
> +common_dep += dep_audit
> +endif
> +endif
> +
>  glx_inc = include_directories('glx')
>  
>  top_srcdir_inc = include_directories('.')
> diff --git a/meson_options.txt b/meson_options.txt
> index 8c600f3986d8..3f02d5066448 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -80,6 +80,8 @@ option('xres', type: 'boolean', value: true,
> description: 'XRes extension')
>  option('xace', type: 'boolean', value: true,
> description: 'X-ACE extension')
> +option('xselinux', type: 'combo', choices: ['true', 'false', 'auto'], value: 
> 'auto',
> +   description: 'XSELINUX extension')
>  option('xinerama', type: 'boolean', value: true,
> description: 'Xinerama extension')
>  option('xcsecurity', type: 'boolean', value: false,
> -- 
> 2.18.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] dix: check_modmap_change() returns Success, not true

[Peter Hutterer]

Not sure what if anything calls XSetDeviceModifierMapping() but this would've
failed all the time. check_modmap_change() returns Successs but we were
treating it like a boolean. Fix this.

Reported-by: Adam Jackson 
Signed-off-by: Peter Hutterer 
---
 dix/inpututils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dix/inpututils.c b/dix/inpututils.c
index 6bff9efab..c51c83547 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -282,7 +282,7 @@ change_modmap(ClientPtr client, DeviceIntPtr dev, KeyCode 
*modkeymap,
 else if (!IsFloating(dev) &&
  GetMaster(dev, MASTER_KEYBOARD)->lastSlave == dev) {
 /* If this fails, expect the results to be weird. */
-if (check_modmap_change(client, dev->master, modmap))
+if (check_modmap_change(client, dev->master, modmap) == Success)
 do_modmap_change(client, dev->master, modmap);
 }
 
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 10/10] meson: Add detection of libsystemd-daemon.

[Peter Hutterer]

On Tue, Aug 07, 2018 at 04:23:19PM -0700, Eric Anholt wrote:
> This enables Xtrans's systemd socket activation.
> 
> Signed-off-by: Eric Anholt 
> ---
>  include/meson.build | 3 ++-
>  meson.build | 7 +++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/meson.build b/include/meson.build
> index 2c139e6b0651..9a7547c4708a 100644
> --- a/include/meson.build
> +++ b/include/meson.build
> @@ -72,7 +72,8 @@ elif cc.compiles('''
>  endif
>  
>  conf_data.set('HAVE_LIBBSD', libbsd_dep.found())
> -# XXX: HAVE_SYSTEMD_DAEMON
> +# Note: this symbol is used by libXtrans.
> +conf_data.set('HAVE_SYSTEMD_DAEMON', libsystemd_daemon_dep.found())
>  conf_data.set('CONFIG_UDEV', build_udev)
>  conf_data.set('CONFIG_UDEV_KMS', build_udev)
>  conf_data.set('HAVE_DBUS', build_dbus)
> diff --git a/meson.build b/meson.build
> index 8c21c646ab89..5275373bd3b4 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -96,6 +96,12 @@ nettle_dep = dependency('nettle')
>  dbus_required = get_option('systemd_logind') == 'true'
>  dbus_dep = dependency('dbus-1', version: '>= 1.0', required: dbus_required)
>  
> +# libsystemd-daemon was moved into libsystemd in version 209
> +libsystemd_daemon_dep = dependency('libsystemd', version: '>= 209', 
> required: false)
> +if not libsystemd_daemon_dep.found()
> +libsystemd_daemon_dep = dependency('libsystemd-daemon', required: false)
> +endif

we require meson > 0.42, released Sep 2017, but check for systemd > 209,
released in Feb 2014. even e.g. RHEL7 is on systemd 219. IMO you can drop
the second three lines here. 

but either way, series is
Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> +
>  build_hashtable = false
>  
>  # Resolve default values of some options
> @@ -452,6 +458,7 @@ common_dep = [
>  xcmiscproto_dep,
>  bigreqsproto_dep,
>  xtrans_dep,
> +libsystemd_daemon_dep,
>  
>  videoproto_dep,
>  compositeproto_dep,
> -- 
> 2.18.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 6/6] meson: Automatically detect HAVE_PTHREAD_SETNAME_NP

[Peter Hutterer]

On Wed, Aug 01, 2018 at 01:49:54PM -0700, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 

series Reviewed-by: Peter Hutterer 

Cheers,
   Peter

> ---
>  include/meson.build | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/include/meson.build b/include/meson.build
> index 6ed7cc6ca997..678555692f6d 100644
> --- a/include/meson.build
> +++ b/include/meson.build
> @@ -58,7 +58,23 @@ conf_data.set('HAS_APERTURE_DRV', host_machine.system() == 
> 'openbsd')
>  # XXX: HAVE_LIBDISPATCH
>  conf_data.set_quoted('OSNAME', 'Linux') # XXX
>  conf_data.set('HAVE_INPUTTHREAD', '1') # XXX
> -conf_data.set('HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID', '1') # XXX
> +
> +if cc.compiles('''
> +#define _GNU_SOURCE 1
> +#include 
> +void foo(int bar) { pthread_setname_np(pthread_self(), "example"); }
> +''',
> +name: 'pthread_setname_np(tid, name)')
> +conf_data.set('HAVE_PTHREAD_SETNAME_NP_WITH_TID', 1)
> +elif cc.compiles('''
> +#define _GNU_SOURCE 1
> +#include 
> +void foo(int bar) { pthread_setname_np("example"); }
> +''',
> +name: 'pthread_setname_np(name)')
> +conf_data.set('HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID', 1)
> +endif
> +
>  conf_data.set('HAVE_LIBBSD', libbsd_dep.found())
>  # XXX: HAVE_SYSTEMD_DAEMON
>  conf_data.set('CONFIG_UDEV', build_udev)
> -- 
> 2.18.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH app/fonttosfnt 5/5] Replace _BSD_SOURCE with _DEFAULT_SOURCE

[Peter Hutterer]

On Tue, Jul 31, 2018 at 05:48:54PM +0200, Walter Harms wrote:
> 
> 
> > Peter Hutterer  hat am 31. Juli 2018 um 03:53
> > geschrieben:
> > 
> > 
> > /usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and 
> > _SVID_SOURCE
> > are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
> >  # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use 
> > _DEFAULT_SOURCE"
> 
> 
> Why is is needed in the first place ? (what would break if not set ?)

*shrug*

I honestly don't know and it builds fine here without it. But that doesn't
mean it will anywhere else and for something as rapidly changing as
fonttosfnt it's safer to just leave things be. It might take us another 9
years to release another bugfix release.

Cheers,
   Peter

> > Signed-off-by: Peter Hutterer 
> > ---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 6ce70b7..29169b1 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -22,7 +22,7 @@
> >  SUBDIRS = man
> >  bin_PROGRAMS = fonttosfnt
> >  
> > -AM_CFLAGS = -DXVENDORNAME=\"X.Org\ Foundation\" $(FONTTOSFNT_CFLAGS)
> > -DXVENDORNAMESHORT=\"X.Org\" -D_BSD_SOURCE -D_GNU_SOURCE $(CWARNFLAGS)
> > +AM_CFLAGS = -DXVENDORNAME=\"X.Org\ Foundation\" $(FONTTOSFNT_CFLAGS)
> > -DXVENDORNAMESHORT=\"X.Org\" -D_DEFAULT_SOURCE -D_GNU_SOURCE $(CWARNFLAGS)
> >  fonttosfnt_LDADD = $(FONTTOSFNT_LIBS) -lm
> >  
> >  fonttosfnt_SOURCES =   \
> > -- 
> > 2.17.1
> > 
> > ___
> > xorg-devel@lists.x.org: X.Org development
> > Archives: http://lists.x.org/archives/xorg-devel
> > Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt 3/5] Remove shadowing rc variable

[Peter Hutterer]

All code paths assign rc and heck it immedately after. We can re-use the one
from the outer loop.

Signed-off-by: Peter Hutterer 
---
 read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/read.c b/read.c
index bee518c..98522b5 100644
--- a/read.c
+++ b/read.c
@@ -107,7 +107,7 @@ readFile(char *filename, FontPtr font)
 if(font->numNames == 0 && face->style_name && face->family_name) {
 char *full_name, *unique_name;
 BDF_PropertyRec prop;
-int rc, i;
+int i;
 if(strcmp(face->style_name, "Regular") == 0)
 full_name = sprintf_alloc("%s", face->family_name);
 else
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt 5/5] Replace _BSD_SOURCE with _DEFAULT_SOURCE

[Peter Hutterer]

/usr/include/features.h:184:3: warning: #warning "_BSD_SOURCE and _SVID_SOURCE 
are deprecated, use _DEFAULT_SOURCE" [-Wcpp]
 # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"

Signed-off-by: Peter Hutterer 
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 6ce70b7..29169b1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -22,7 +22,7 @@
 SUBDIRS = man
 bin_PROGRAMS = fonttosfnt
 
-AM_CFLAGS = -DXVENDORNAME=\"X.Org\ Foundation\" $(FONTTOSFNT_CFLAGS) 
-DXVENDORNAMESHORT=\"X.Org\" -D_BSD_SOURCE -D_GNU_SOURCE $(CWARNFLAGS)
+AM_CFLAGS = -DXVENDORNAME=\"X.Org\ Foundation\" $(FONTTOSFNT_CFLAGS) 
-DXVENDORNAMESHORT=\"X.Org\" -D_DEFAULT_SOURCE -D_GNU_SOURCE $(CWARNFLAGS)
 fonttosfnt_LDADD = $(FONTTOSFNT_LIBS) -lm
 
 fonttosfnt_SOURCES =   \
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt 2/5] README: update repository URL to gitlab

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 README | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/README b/README
index 58f1062..fa3ad08 100644
--- a/README
+++ b/README
@@ -12,9 +12,7 @@ Please submit bug reports to the Xorg bugzilla:
 
 The master development code repository can be found at:
 
-git://anongit.freedesktop.org/git/xorg/app/fonttosfnt
-
-http://cgit.freedesktop.org/xorg/app/fonttosfnt
+https://gitlab.freedesktop.org/xorg/app/fonttosfnt.git
 
 For patch submission instructions, see:
 
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt 4/5] Fix shadowing i variable complaint

[Peter Hutterer]

C99 is a magical thing!

Signed-off-by: Peter Hutterer 
---
 read.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/read.c b/read.c
index 98522b5..632c7e7 100644
--- a/read.c
+++ b/read.c
@@ -58,7 +58,7 @@ FT_Ensure_Inited(void)
 int
 readFile(char *filename, FontPtr font)
 {
-int i, j, k, index;
+int j, k, index;
 int rc;
 FT_Face face;
 StrikePtr strike;
@@ -234,7 +234,7 @@ readFile(char *filename, FontPtr font)
 return -1;
 }
 
-for(i = 0; i < face->num_fixed_sizes; i++) {
+for(int i = 0; i < face->num_fixed_sizes; i++) {
 if(verbose_flag)
 fprintf(stderr, "size %d: %dx%d\n",
 i, 
@@ -294,7 +294,7 @@ readFile(char *filename, FontPtr font)
 FT_Done_Face(face);
 
 j = 0;
-for(i = 0; i < FONT_CODES; i++) {
+for(int i = 0; i < FONT_CODES; i++) {
 int found = 0;
 strike = font->strikes;
 while(strike) {
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH app/fonttosfnt 1/5] Constify a few string arguments

[Peter Hutterer]

Cuts down on compiler warning by at least 64%, what a bargain!

Signed-off-by: Peter Hutterer 
---
 fonttosfnt.h |  8 
 util.c   | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/fonttosfnt.h b/fonttosfnt.h
index d6aa004..159535f 100644
--- a/fonttosfnt.h
+++ b/fonttosfnt.h
@@ -166,10 +166,10 @@ int writeFile(char *filename, FontPtr);
 #define PROP_INTEGER 2
 #define PROP_CARDINAL 3
 
-char *sprintf_alloc(char *f, ...);
-char *vsprintf_alloc(char *f, va_list args);
-char *makeUTF16(char *);
-unsigned makeName(char*);
+char *sprintf_alloc(const char *f, ...);
+char *vsprintf_alloc(const char *f, va_list args);
+char *makeUTF16(const char *);
+unsigned makeName(const char*);
 int macTime(int *, unsigned *);
 unsigned faceFoundry(FT_Face);
 char *faceEncoding(FT_Face);
diff --git a/util.c b/util.c
index 72ca9b9..81c0489 100644
--- a/util.c
+++ b/util.c
@@ -69,7 +69,7 @@ extern void unsetenv(const char *name);
 #endif
 
 char*
-sprintf_alloc(char *f, ...)
+sprintf_alloc(const char *f, ...)
 {
 char *s;
 va_list args;
@@ -81,7 +81,7 @@ sprintf_alloc(char *f, ...)
 
 #if HAVE_VASPRINTF
 char*
-vsprintf_alloc(char *f, va_list args)
+vsprintf_alloc(const char *f, va_list args)
 {
 char *r;
 int rc;
@@ -93,7 +93,7 @@ vsprintf_alloc(char *f, va_list args)
 }
 #else
 char*
-vsprintf_alloc(char *f, va_list args)
+vsprintf_alloc(const char *f, va_list args)
 {
 int n, size = 12;
 char *string;
@@ -127,7 +127,7 @@ vsprintf_alloc(char *f, va_list args)
 /* Build a UTF-16 string from a Latin-1 string.  
Result is not NUL-terminated. */
 char *
-makeUTF16(char *string)
+makeUTF16(const char *string)
 {
 int i;
 int n = strlen(string);
@@ -142,7 +142,7 @@ makeUTF16(char *string)
 }
 
 unsigned
-makeName(char *s)
+makeName(const char *s)
 {
 return s[0] << 24 | s[1] << 16 | s[2] << 8 | s[3];
 }
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH app/xev] xev: fix 'mode' in default case (version 2)

[Peter Hutterer]

On Sat, Jul 28, 2018 at 08:28:36AM +, Eitan Adler wrote:
> Signed-off-by: Eitan Adler 

To ssh://gitlab.freedesktop.org/xorg/app/xev
   d1f08f6..25bb70e  master -> master

thanks

Cheers,
   Peter

> ---
>  xev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/xev.c b/xev.c
> index 6cde09a..638eae7 100644
> --- a/xev.c
> +++ b/xev.c
> @@ -225,7 +225,7 @@ do_EnterNotify (XEvent *eventp)
>case NotifyGrab:  mode = "NotifyGrab"; break;
>case NotifyUngrab:  mode = "NotifyUngrab"; break;
>case NotifyWhileGrabbed:  mode = "NotifyWhileGrabbed"; break;
> -  default:  mode = dmode, sprintf (dmode, "%u", e->mode); break;
> +  default:  mode = dmode; sprintf (dmode, "%u", e->mode); break;
>  }
>  
>  switch (e->detail) {
> @@ -265,7 +265,7 @@ do_FocusIn (XEvent *eventp)
>case NotifyGrab:  mode = "NotifyGrab"; break;
>case NotifyUngrab:  mode = "NotifyUngrab"; break;
>case NotifyWhileGrabbed:  mode = "NotifyWhileGrabbed"; break;
> -  default:  mode = dmode, sprintf (dmode, "%u", e->mode); break;
> +  default:  mode = dmode; sprintf (dmode, "%u", e->mode); break;
>  }
>  
>  switch (e->detail) {
> -- 
> 2.18.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: xmodmap really slow

[Peter Hutterer]

On Thu, Jul 26, 2018 at 12:25:49PM +0100, Alan Hourihane wrote:
> Anyone tried just doing this recently
> 
> xmodmap -pke > /tmp/keydump
> xmodmap /tmp/keydump
> 
> And watch the Xserver hang for quite some time.

anything in the log? Just tried this locally and it worked just fine.
what server version are you on?

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] Xext: dynamically allocate the PanoramiXDepths[j].vids array

[Peter Hutterer]

On Tue, Jul 17, 2018 at 10:12:55PM -0700, Keith Packard wrote:
> Peter Hutterer  writes:
> 
> > Control flow is:
> >PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
> >PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
> >and writes those into the previously allocated array.
> >
> > This caused invalid reads/writes followed by eventually a double-free abort.
> >
> > Reproduced with xorg-integration-tests server test
> > XineramaTest.ScreenCrossing/* (and a bunch of others).
> >
> > Signed-off-by: Peter Hutterer 
> 
> Reviewed-by: Keith Packard 
> 
> (I'd complain about the lack of NULL check, but the original code didn't
> bother either)

I suspect our overall behaviour where malloc fails is somewhere between
unpredictable and undefined. I don't think any of that code has ever been
tested and right now it probably just means we fall over somewhere else than
where it actually happened.

Thanks for the quick review, much appreciated.

To gitlab.freedesktop.org:xorg/xserver.git
   1c7f34e99..93cafb082  master -> master

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] Xext: dynamically allocate the PanoramiXDepths[j].vids array

[Peter Hutterer]

Control flow is:
   PanoramiXMaybeAddDepth() allocates an array size 240 (pDepth->numVisuals)
   PanoramiXMaybeAddVisual() finds up to 270 matches (pScreen->numVisuals)
   and writes those into the previously allocated array.

This caused invalid reads/writes followed by eventually a double-free abort.

Reproduced with xorg-integration-tests server test
XineramaTest.ScreenCrossing/* (and a bunch of others).

Signed-off-by: Peter Hutterer 
---
 Xext/panoramiX.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/Xext/panoramiX.c b/Xext/panoramiX.c
index 844ea49ce..bd9c45b03 100644
--- a/Xext/panoramiX.c
+++ b/Xext/panoramiX.c
@@ -751,11 +751,7 @@ PanoramiXMaybeAddDepth(DepthPtr pDepth)
PanoramiXNumDepths, sizeof(DepthRec));
 PanoramiXDepths[j].depth = pDepth->depth;
 PanoramiXDepths[j].numVids = 0;
-/* XXX suboptimal, should grow these dynamically */
-if (pDepth->numVids)
-PanoramiXDepths[j].vids = xallocarray(pDepth->numVids, 
sizeof(VisualID));
-else
-PanoramiXDepths[j].vids = NULL;
+PanoramiXDepths[j].vids = NULL;
 }
 
 static void
@@ -796,6 +792,9 @@ PanoramiXMaybeAddVisual(VisualPtr pVisual)
 
 for (k = 0; k < PanoramiXNumDepths; k++) {
 if (PanoramiXDepths[k].depth == pVisual->nplanes) {
+PanoramiXDepths[k].vids = reallocarray(PanoramiXDepths[k].vids,
+   PanoramiXDepths[k].numVids 
+ 1,
+   sizeof(VisualID));
 PanoramiXDepths[k].vids[PanoramiXDepths[k].numVids] = pVisual->vid;
 PanoramiXDepths[k].numVids++;
 break;
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] draglock: fix memory overwrite during draglock parsing

[Peter Hutterer]

Passing in the size of the array but using it as "number of elements" inside
the function. Rename a bunch of arguments to avoid this.

https://bugs.freedesktop.org/show_bug.cgi?id=107166

Signed-off-by: Peter Hutterer 
---
Martin: this is the same basic change as your patch in 107166, but a lot
more garnish to change from the ambiguous "sz" to the less ambiguous
"nelem".

 src/draglock.c | 14 +++---
 src/draglock.h |  6 +++---
 src/xf86libinput.c |  2 +-
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/draglock.c b/src/draglock.c
index b0bcac3..e0a91d0 100644
--- a/src/draglock.c
+++ b/src/draglock.c
@@ -116,7 +116,7 @@ draglock_get_meta(const struct draglock *dl)
 }
 
 size_t
-draglock_get_pairs(const struct draglock *dl, int *array, size_t sz)
+draglock_get_pairs(const struct draglock *dl, int *array, size_t nelem)
 {
unsigned int i;
size_t last = 0;
@@ -131,8 +131,8 @@ draglock_get_pairs(const struct draglock *dl, int *array, 
size_t sz)
}
 
/* size N array with a[0] == 0, the rest ordered by button number */
-   memset(array, 0, sz * sizeof(array[0]));
-   for (i = 0; i < sz && i < ARRAY_SIZE(dl->lock_pair); i++) {
+   memset(array, 0, nelem * sizeof(array[0]));
+   for (i = 0; i < nelem && i < ARRAY_SIZE(dl->lock_pair); i++) {
array[i] = dl->lock_pair[i];
if (array[i] != 0 && i > last)
last = i;
@@ -153,20 +153,20 @@ draglock_set_meta(struct draglock *dl, int meta_button)
 }
 
 int
-draglock_set_pairs(struct draglock *dl, const int *array, size_t sz)
+draglock_set_pairs(struct draglock *dl, const int *array, size_t nelem)
 {
unsigned int i;
 
-   if (sz == 0 || array[0] != 0)
+   if (nelem == 0 || array[0] != 0)
return 1;
 
-   for (i = 0; i < sz; i++) {
+   for (i = 0; i < nelem; i++) {
if (array[i] < 0 || array[i] >= DRAGLOCK_MAX_BUTTONS)
return 1;
}
 
dl->mode = DRAGLOCK_DISABLED;
-   for (i = 0; i < sz; i++) {
+   for (i = 0; i < nelem; i++) {
dl->lock_pair[i] = array[i];
if (dl->lock_pair[i])
dl->mode = DRAGLOCK_PAIRS;
diff --git a/src/draglock.h b/src/draglock.h
index acc1314..900d538 100644
--- a/src/draglock.h
+++ b/src/draglock.h
@@ -107,13 +107,13 @@ draglock_get_meta(const struct draglock *dl);
  * @note Button numbers start at 1, array[0] is always 0.
  *
  * @param[in|out] array Caller-allocated array to hold the button mappings.
- * @param[in] sz Maximum number of elements in array
+ * @param[in] nelem Maximum number of elements in array
  *
  * @return The number of valid elements in array or 0 if the current mode is
  * not DRAGLOCK_PAIRS
  */
 size_t
-draglock_get_pairs(const struct draglock *dl, int *array, size_t sz);
+draglock_get_pairs(const struct draglock *dl, int *array, size_t nelem);
 
 /**
  * Set the drag lock config to the DRAGLOCK_META mode, with the given
@@ -140,7 +140,7 @@ draglock_set_meta(struct draglock *dl, int meta_button);
  * @return 0 on successor nonzero otherwise
  */
 int
-draglock_set_pairs(struct draglock *dl, const int *array, size_t sz);
+draglock_set_pairs(struct draglock *dl, const int *array, size_t nelem);
 
 /**
  * Process the given button event through the drag lock state machine.
diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 2e950cd..34f1102 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -5326,7 +5326,7 @@ LibinputInitDragLockProperty(DeviceIntPtr dev,
break;
case DRAGLOCK_PAIRS:
sz = draglock_get_pairs(_data->draglock,
-   dl_values, sizeof(dl_values));
+   dl_values, ARRAY_SIZE(dl_values));
break;
default:
xf86IDrvMsg(dev->public.devicePrivate,
-- 
2.17.1

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH man xmodmap] Removing reference to XKeysymDB

[Peter Hutterer]

On Thu, Jul 05, 2018 at 02:58:49PM +0200, Wolfgang Pfeiffer wrote:
> Removing a reference in 'man xmodmap' to a file called XKeysymDB that
> was, IIUC, already remvoved around 2010 - please see:
> 
> https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=eb023c0f8919e809b8b609e1467b14d20a290aa7
> 
> I'm not sure whether that "(without the \fIXK_\fP prefix)" part still
> being in the changed text should be removed as well.
> 
> Please note I'm not familiar with writing patches. I hope the change
> can be applied successfully.
> 
> Responses: please CC me - I'm not subscribed to this list.

thank you, pushed as c4df95c..9be2aca  master -> master

Cheers,
   Peter


> --- orig/xmodmap-1.0.9/man/xmodmap.man2015-04-17 09:07:11.0 
> +0200
> +++ new/xmodmap-1.0.9/man/xmodmap.man 2018-07-05 14:14:57.406650883 +0200
> @@ -143,8 +143,7 @@
>  conflicts.
>  .PP
>  The list of keysym names may be found in the header file
> -\fI\fP (without the \fIXK_\fP prefix),
> -supplemented by the keysym database \fI __X11datadir__/XKeysymDB\fP.
> +\fI\fP (without the \fIXK_\fP prefix).
>  Keysyms matching Unicode characters may be specified as "U0020" to "U007E"
>  and "U00A0" to "U10" for all possible Unicode characters.
>  .TP 8

> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] meson: use absolute paths in manpage substitutions

[Peter Hutterer]

On Sat, Jun 30, 2018 at 12:53:35PM +0100, Jon Turney wrote:
> paths returned by get_option('foodir') are potentially relative to prefix
> 
> Noticed when comparing manpages generated by a meson build with those
> generated by an autotools build
> 
> Signed-off-by: Jon Turney 

pushed, thanks

To git+ssh://git.freedesktop.org/git/xorg/xserver
   38ff29ec8..49283e238  master -> master

Cheers,
   Peter

> ---
>  meson.build | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index f2c71fe27..706228228 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -520,9 +520,9 @@ manpage_config.set('libmansuffix', '3')
>  manpage_config.set('miscmansuffix', '7')
>  manpage_config.set('filemansuffix', '5')
>  manpage_config.set('logdir', log_dir)
> -manpage_config.set('datadir', get_option('datadir'))
> -manpage_config.set('mandir', get_option('mandir'))
> -manpage_config.set('sysconfdir', get_option('sysconfdir'))
> +manpage_config.set('datadir', join_paths(get_option('prefix'), 
> get_option('datadir')))
> +manpage_config.set('mandir', join_paths(get_option('prefix'), 
> get_option('mandir')))
> +manpage_config.set('sysconfdir', join_paths(get_option('prefix'), 
> get_option('sysconfdir')))
>  manpage_config.set('xconfigdir', 'xorg.conf.d')
>  manpage_config.set('xkbdir', xkb_dir)
>  manpage_config.set('XKB_DFLT_RULES', get_option('xkb_default_rules'))
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] meson: Add configuration of listening on tcp, unix and local

[Peter Hutterer]

On Fri, Jun 29, 2018 at 09:44:27AM +0200, Laurent Carlier wrote:
> Le jeudi 28 juin 2018, 07:16:42 CEST Peter Hutterer a écrit :
> > On Tue, Jun 26, 2018 at 09:51:58PM -0700, Aaron Plattner wrote:
> > > On 06/26/2018 06:12 PM, Peter Hutterer wrote:
> > > > On Tue, Jun 26, 2018 at 01:07:23PM -0700, Aaron Plattner wrote:
> > > > > On 06/24/2018 11:45 PM, Laurent Carlier wrote:
> > > > > > Le samedi 16 juin 2018, 13:00:01 CEST Laurent Carlier a écrit :
> > > > > > > bugzilla: https://bugs.kde.org/show_bug.cgi?id=395419
> > > > > > > bugzilla: https://bugs.archlinux.org/task/59025
> > > > > > > 
> > > > > > > Signed-off-by: Laurent Carlier 
> > > > > 
> > > > > Seems to work, so
> > > > > Reviewed-by: Aaron Plattner 
> > > > > 
> > > > > This switches the defined version from
> > > > > #define LISTEN_TCP 1
> > > > > to
> > > > > #define LISTEN_TCP
> > > > > but it's only used in an #ifndef so that's probably fine.
> > > > 
> > > > best to change to meson's conf_data.set10() then to keep the exact
> > > > functionality.
> > > 
> > > No, that's worse. Then "meson -Dlisten_tcp=false" does this:
> > > 
> > > #define LISTEN_TCP 0
> > > 
> > > which will enable TCP. Thanks, 1989 C preprocessor.
> > 
> > rightyo. Pushed:
> > 
> >c41d4ff48..2f39b2a07  master -> master
> > 
> > 
> > Cheers,
> >Peter
> > 
> 
> You've forgotten the gitlab repo

there is a gitlab repo for the server? where is it hiding?

https://gitlab.freedesktop.org/xorg/ shows nothing and
https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/40 indicates
that it's not done yet either.

Cheers,
   Peter

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] meson: Add configuration of listening on tcp, unix and local

[Peter Hutterer]

On Tue, Jun 26, 2018 at 09:51:58PM -0700, Aaron Plattner wrote:
> On 06/26/2018 06:12 PM, Peter Hutterer wrote:
> > On Tue, Jun 26, 2018 at 01:07:23PM -0700, Aaron Plattner wrote:
> > > On 06/24/2018 11:45 PM, Laurent Carlier wrote:
> > > > Le samedi 16 juin 2018, 13:00:01 CEST Laurent Carlier a écrit :
> > > > > bugzilla: https://bugs.kde.org/show_bug.cgi?id=395419
> > > > > bugzilla: https://bugs.archlinux.org/task/59025
> > > > > 
> > > > > Signed-off-by: Laurent Carlier 
> > > 
> > > Seems to work, so
> > > Reviewed-by: Aaron Plattner 
> > > 
> > > This switches the defined version from
> > > #define LISTEN_TCP 1
> > > to
> > > #define LISTEN_TCP
> > > but it's only used in an #ifndef so that's probably fine.
> > 
> > best to change to meson's conf_data.set10() then to keep the exact
> > functionality.
> 
> No, that's worse. Then "meson -Dlisten_tcp=false" does this:
> 
> #define LISTEN_TCP 0
> 
> which will enable TCP. Thanks, 1989 C preprocessor.

rightyo. Pushed:

   c41d4ff48..2f39b2a07  master -> master


Cheers,
   Peter

> > > > >   include/meson.build | 6 +++---
> > > > >   meson_options.txt   | 7 +++
> > > > >   2 files changed, 10 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/include/meson.build b/include/meson.build
> > > > > index f76f557..dfca3c3 100644
> > > > > --- a/include/meson.build
> > > > > +++ b/include/meson.build
> > > > > @@ -153,10 +153,10 @@ conf_data.set('BUSFAULT',
> > > > > conf_data.get('HAVE_SIGACTION')) conf_data.set('_XTYPEDEF_POINTER', 
> > > > > '1')
> > > > >   conf_data.set('_XITYPEDEF_POINTER', '1')
> > > > > 
> > > > > +conf_data.set('LISTEN_TCP', get_option('listen_tcp'))
> > > > > +conf_data.set('LISTEN_UNIX', get_option('listen_unix'))
> > > > > +conf_data.set('LISTEN_LOCAL', get_option('listen_local'))
> > > > >   # XXX: Configurable?
> > > > > -conf_data.set('LISTEN_TCP', '1')
> > > > > -conf_data.set('LISTEN_UNIX', '1')
> > > > > -conf_data.set('LISTEN_LOCAL', '1')
> > > > >   conf_data.set('XTRANS_SEND_FDS', '1')
> > > > > 
> > > > >   conf_data.set('TCPCONN', '1')
> > > > > diff --git a/meson_options.txt b/meson_options.txt
> > > > > index 86fca46..3453b8d 100644
> > > > > --- a/meson_options.txt
> > > > > +++ b/meson_options.txt
> > > > > @@ -45,6 +45,13 @@ option('vendor_name_short', type: 'string', value:
> > > > > 'X.Org') option('vendor_web', type: 'string', value: 
> > > > > 'http://wiki.x.org')
> > > > >   option('os_vendor', type: 'string', value: '')
> > > > > 
> > > > > +option('listen_tcp', type: 'boolean', value: false,
> > > > > +   description: 'Listen on TCP by default')
> > > > > +option('listen_unix', type: 'boolean', value: true,
> > > > > +   description: 'Listen on Unix by default')
> > > > > +option('listen_local', type: 'boolean', value: true,
> > > > > +   description: 'Listen on local by default')
> > > > > +
> > > > >   option('int10', type: 'combo', choices: ['stub', 'x86emu', 'vm86', 
> > > > > 'auto',
> > > > > 'false'], value: 'auto',
> > > > >  description: 'Xorg int10 backend (default: usually x86emu)')
> > > > 
> > > > Humble ping ?
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > xorg-devel@lists.x.org: X.Org development
> > > > Archives: http://lists.x.org/archives/xorg-devel
> > > > Info: https://lists.x.org/mailman/listinfo/xorg-devel
> > > > 
> > > 
> > > ___
> > > xorg-devel@lists.x.org: X.Org development
> > > Archives: http://lists.x.org/archives/xorg-devel
> > > Info: https://lists.x.org/mailman/listinfo/xorg-devel
> > > 
> > 
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Improve the ButtonInfo description.

[Peter Hutterer]

On Tue, Jun 26, 2018 at 04:49:21PM +0100, Emil Velikov wrote:
> On 8 June 2018 at 01:59, Peter Hutterer  wrote:
> > On Thu, Jun 07, 2018 at 03:32:08AM +0200, Roman Kapl wrote:
> >> It failed to mention it is followed by a bit-mask and then the atoms.
> >>
> >> Signed-off-by: Roman Kapl 
> >> ---
> >>  include/X11/extensions/XI2proto.h | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > Patch content is correct, thanks. But what repository did you make this
> > patch to?  This should go into the inputproto repo but it has the XI2proto.h
> > in the root tree.
> >
> AFAICT this patch is against xorgproto, which I believe is the way forward?
> The inputproto autogen.sh seems fairly clear about it.

indeed, thanks. I really need to pull more often...
Pushed to xorgproto:
eb28f03..af9b5f4  master -> master

Cheers,
   Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xfree86: Makefile shouldn't rely on superuser being named 'root'

[Peter Hutterer]

On Mon, Jun 11, 2018 at 05:17:31PM -0400, Adam Jackson wrote:
> From: Michał Górny 
> 
> Change the 'chown' statement in Makefile.am to use the numeric UID
> of superuser instead of relying on the name 'root'.
> 
> Bugzilla: https://bugs.freedesktop.org/27726
> Signed-off-by: Adam Jackson 
> Signed-off-by: Michał Górny 
> ---

Reviewed-by: Peter Hutterer 

Cheers,
   Peter

>  hw/xfree86/Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am
> index 57c8b8dd45..9aeaea1a66 100644
> --- a/hw/xfree86/Makefile.am
> +++ b/hw/xfree86/Makefile.am
> @@ -108,14 +108,14 @@ endif
>  install-exec-hook:
>   (cd $(DESTDIR)$(bindir) && rm -f X && $(LN_S) Xorg$(EXEEXT) X)
>  if INSTALL_SETUID
> - chown root $(DESTDIR)$(bindir)/Xorg
> + chown 0 $(DESTDIR)$(bindir)/Xorg
>   chmod u+s $(DESTDIR)$(bindir)/Xorg
>  endif
>  if SUID_WRAPPER
>   $(MKDIR_P) $(DESTDIR)$(SUID_WRAPPER_DIR)
>   mv $(DESTDIR)$(bindir)/Xorg $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg
>   ${INSTALL} -m 755 Xorg.sh $(DESTDIR)$(bindir)/Xorg
> - -chown root $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg.wrap && chmod u+s 
> $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg.wrap
> + -chown 0 $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg.wrap && chmod u+s 
> $(DESTDIR)$(SUID_WRAPPER_DIR)/Xorg.wrap
>  endif
>  
>  uninstall-local:
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: add "tablet" into the tablet device names

[Peter Hutterer]

On Mon, Jun 11, 2018 at 11:21:25AM +0200, Olivier Fourdan wrote:
> Hi Peter,
> On Mon, 11 Jun 2018 at 01:12, Peter Hutterer  wrote:
> >
> > Changes the device name from "xwayland-stylus" to "xwayland-tablet stylus".
> > This doesn't fully address #26 but it goes a little step into making it more
> > human-readable.
> >
> > https://gitlab.freedesktop.org/wayland/wayland/issues/26
> >
> > Signed-off-by: Peter Hutterer 
> > ---
> >  hw/xwayland/xwayland-input.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> > index 0a37f97bd..a602f0887 100644
> > --- a/hw/xwayland/xwayland-input.c
> > +++ b/hw/xwayland/xwayland-input.c
> > @@ -1389,19 +1389,19 @@ tablet_handle_done(void *data, struct zwp_tablet_v2 
> > *tablet)
> >  struct xwl_seat *xwl_seat = xwl_tablet->seat;
> >
> >  if (xwl_seat->stylus == NULL) {
> > -xwl_seat->stylus = add_device(xwl_seat, "xwayland-stylus", 
> > xwl_tablet_proc);
> > +xwl_seat->stylus = add_device(xwl_seat, "xwayland-tablet stylus", 
> > xwl_tablet_proc);
> >  ActivateDevice(xwl_seat->stylus, TRUE);
> >  }
> >  EnableDevice(xwl_seat->stylus, TRUE);
> >
> >  if (xwl_seat->eraser == NULL) {
> > -xwl_seat->eraser = add_device(xwl_seat, "xwayland-eraser", 
> > xwl_tablet_proc);
> > +xwl_seat->eraser = add_device(xwl_seat, "xwayland-tablet eraser", 
> > xwl_tablet_proc);
> >  ActivateDevice(xwl_seat->eraser, TRUE);
> >  }
> >  EnableDevice(xwl_seat->eraser, TRUE);
> >
> >  if (xwl_seat->puck == NULL) {
> > -xwl_seat->puck = add_device(xwl_seat, "xwayland-cursor", 
> > xwl_tablet_proc);
> > +xwl_seat->puck = add_device(xwl_seat, "xwayland-tablet cursor", 
> > xwl_tablet_proc);
> >  ActivateDevice(xwl_seat->puck, TRUE);
> >  }
> >  EnableDevice(xwl_seat->puck, TRUE);
> > @@ -2147,7 +2147,7 @@ tablet_pad_done(void *data,
> >  {
> >  struct xwl_tablet_pad *pad = data;
> >
> > -pad->xdevice = add_device(pad->seat, "xwayland-pad",
> > +pad->xdevice = add_device(pad->seat, "xwayland-tablet-pad",
> 
> Previous ones used a space, here you use a dash between
> “xwayland-tablet” and the device type, I'd rather have that
> consistent.

at the risk of disagreeing over the optical appearance of a velocipede
storage environment: the xwayland-tablet-pad refers to an interface in the
same way as xwayland-tablet does. The space-separated part is the tool which
we only have in the tablet interface, not the tablet-pad one.

Not that any of this really matters for the user who sees this :)

Cheers,
   Peter

> 
> >xwl_tablet_pad_proc);
> >  pad->xdevice->public.devicePrivate = pad;
> >  ActivateDevice(pad->xdevice, TRUE);
> > --
> > 2.14.4
> >
> > ___
> > wayland-devel mailing list
> > wayland-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
> Sounds like a reasonable thing to do... with a pretty low risk.
> 
> With the consistency nit picking addressed:
> 
> Reviewed-by: Olivier Fourdan 
> 
> Cheers,
> Olivier
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] xwayland: add "tablet" into the tablet device names

[Peter Hutterer]

Changes the device name from "xwayland-stylus" to "xwayland-tablet stylus".
This doesn't fully address #26 but it goes a little step into making it more
human-readable.

https://gitlab.freedesktop.org/wayland/wayland/issues/26

Signed-off-by: Peter Hutterer 
---
 hw/xwayland/xwayland-input.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 0a37f97bd..a602f0887 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -1389,19 +1389,19 @@ tablet_handle_done(void *data, struct zwp_tablet_v2 
*tablet)
 struct xwl_seat *xwl_seat = xwl_tablet->seat;
 
 if (xwl_seat->stylus == NULL) {
-xwl_seat->stylus = add_device(xwl_seat, "xwayland-stylus", 
xwl_tablet_proc);
+xwl_seat->stylus = add_device(xwl_seat, "xwayland-tablet stylus", 
xwl_tablet_proc);
 ActivateDevice(xwl_seat->stylus, TRUE);
 }
 EnableDevice(xwl_seat->stylus, TRUE);
 
 if (xwl_seat->eraser == NULL) {
-xwl_seat->eraser = add_device(xwl_seat, "xwayland-eraser", 
xwl_tablet_proc);
+xwl_seat->eraser = add_device(xwl_seat, "xwayland-tablet eraser", 
xwl_tablet_proc);
 ActivateDevice(xwl_seat->eraser, TRUE);
 }
 EnableDevice(xwl_seat->eraser, TRUE);
 
 if (xwl_seat->puck == NULL) {
-xwl_seat->puck = add_device(xwl_seat, "xwayland-cursor", 
xwl_tablet_proc);
+xwl_seat->puck = add_device(xwl_seat, "xwayland-tablet cursor", 
xwl_tablet_proc);
 ActivateDevice(xwl_seat->puck, TRUE);
 }
 EnableDevice(xwl_seat->puck, TRUE);
@@ -2147,7 +2147,7 @@ tablet_pad_done(void *data,
 {
 struct xwl_tablet_pad *pad = data;
 
-pad->xdevice = add_device(pad->seat, "xwayland-pad",
+pad->xdevice = add_device(pad->seat, "xwayland-tablet-pad",
   xwl_tablet_pad_proc);
 pad->xdevice->public.devicePrivate = pad;
 ActivateDevice(pad->xdevice, TRUE);
-- 
2.14.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/2] Xi: add forgotten byte-swaps for Valuator fields

[Peter Hutterer]

On Thu, Jun 07, 2018 at 03:31:42AM +0200, Roman Kapl wrote:
> This has caused nonsensical values in xinput output.
> 
> Signed-off-by: Roman Kapl 
> ---
>  Xi/xiquerydevice.c | 3 +++
>  1 file changed, 3 insertions(+)

pushed, thanks

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: E: failed to find patch for rev 
cefbc6a9356e5c6cf935b61557efa897762defae.
remote: I: patch #228063 updated using rev 
40586cc4f8faa271d62fd84fe98c41debb878984.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/xserver
   9b8999411..40586cc4f  master -> master

Cheers,
   Peter

> 
> diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c
> index 5f5a5f82f..fbb51fe81 100644
> --- a/Xi/xiquerydevice.c
> +++ b/Xi/xiquerydevice.c
> @@ -383,6 +383,9 @@ SwapValuatorInfo(DeviceIntPtr dev, xXIValuatorInfo * info)
>  swapl(>min.frac);
>  swapl(>max.integral);
>  swapl(>max.frac);
> +swapl(>value.integral);
> +swapl(>value.frac);
> +swapl(>resolution);
>  swaps(>number);
>  swaps(>sourceid);
>  }
> -- 
> 2.17.1
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] Improve the ButtonInfo description.

[Peter Hutterer]

On Thu, Jun 07, 2018 at 03:32:08AM +0200, Roman Kapl wrote:
> It failed to mention it is followed by a bit-mask and then the atoms.
> 
> Signed-off-by: Roman Kapl 
> ---
>  include/X11/extensions/XI2proto.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

Patch content is correct, thanks. But what repository did you make this
patch to?  This should go into the inputproto repo but it has the XI2proto.h
in the root tree.

Cheers,
   Peter

> 
> diff --git a/include/X11/extensions/XI2proto.h 
> b/include/X11/extensions/XI2proto.h
> index 4cdaa0d..28a9062 100644
> --- a/include/X11/extensions/XI2proto.h
> +++ b/include/X11/extensions/XI2proto.h
> @@ -149,8 +149,9 @@ typedef struct {
>  
>  /**
>   * Denotes button capability on a device.
> - * Struct is followed by num_buttons * Atom that names the buttons in the
> - * device-native setup (i.e. ignoring button mappings).
> + * Struct is followed by a button bit-mask (padded to four byte chunks) and
> + * then num_buttons * Atom that names the buttons in the device-native setup
> + * (i.e.  ignoring button mappings).
>   */
>  typedef struct {
>  uint16_ttype;   /**< Always ButtonClass */
> -- 
> 2.17.1
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xkbcomp] Ignore xkb_keycodes.maximum of > 255

[Peter Hutterer]

Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"

A keymap with a key > 255 will have a xkb_keycodes.maximum of that keycode.
Let's not throw a fatal error on that, just crop it back to the maximum of
255. This doesn't set the "high_keycode_warned" on purpose so we get this for
the first key that actually matters.

Reproducible with xkeyboard-config 2.24 which has a maximum of 374.

https://bugzilla.redhat.com/show_bug.cgi?id=1587998

Signed-off-by: Peter Hutterer 
---
 keycodes.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/keycodes.c b/keycodes.c
index d5ac762..c21f7c4 100644
--- a/keycodes.c
+++ b/keycodes.c
@@ -663,7 +663,7 @@ HandleKeyNameVar(VarDef * stmt, KeyNamesInfo * info)
 ACTION1("Assignment to field %s ignored\n", field.str);
 return 0;
 }
-if ((tmp.ival < XkbMinLegalKeyCode) || (tmp.ival > XkbMaxLegalKeyCode))
+if ((tmp.ival < XkbMinLegalKeyCode))
 {
 ERROR3
 ("Illegal keycode %d (must be in the range %d-%d inclusive)\n",
@@ -671,6 +671,14 @@ HandleKeyNameVar(VarDef * stmt, KeyNamesInfo * info)
 ACTION1("Value of \"%s\" not changed\n", field.str);
 return 0;
 }
+if ((tmp.ival > XkbMaxLegalKeyCode))
+{
+WARN2("Unsupported maximum keycode %d, clipping.\n", tmp.ival);
+ACTION2("X11 cannot support keycodes above 255.\n");
+info->explicitMax = XkbMaxLegalKeyCode;
+info->effectiveMax = XkbMaxLegalKeyCode;
+return 1;
+}
 if (which == MIN_KEYCODE_DEF)
 {
 if ((info->explicitMax > 0) && (info->explicitMax < tmp.ival))
-- 
2.14.4

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH evdev 2/2] Fix generation of proximity-in/out events.

[Peter Hutterer]

From: Andrey Zabolotnyi <zappare...@ya.ru>

Invoking xf86PostProximityEvent with no valuators does nothing, so we
have to provide a valid valuator set to the call.

https://bugs.freedesktop.org/show_bug.cgi?id=104562

[whot: slight change from 104562
abs_vals is reset on every frame but old_vals is kept around to remember the
last value of the valuator (and is updated to the current values before
processing the frame). We expect the prox in to have x/y, so let's just
unconditionally use old_vals for proximity events.]

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 src/evdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/evdev.c b/src/evdev.c
index d07ee0a..6b5eadd 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -915,7 +915,7 @@ EvdevPostProximityEvents(InputInfoPtr pInfo, int which)
 break;
 case EV_QUEUE_PROXIMITY:
 if (pEvdev->queue[i].val == which)
-xf86PostProximityEvent(pInfo->dev, which, 0, 0);
+xf86PostProximityEventM(pInfo->dev, which, 
pEvdev->old_vals);
 break;
 }
 }
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH evdev 1/2] Ignore x/y axis changes on proximity out

[Peter Hutterer]

Wacom tablet send a farewell reset to 0 on all axes when the tool goes out of
proximity. Ignore those so we can rely on our variuos valuator masks always
having the correct coordinates.

Possible false positive if you manage to go out of proximity right above the
zero datum but meh.

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 src/evdev.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index 3d7b6f0..d07ee0a 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -551,6 +551,16 @@ EvdevProcessProximityState(InputInfoPtr pInfo)
 }
 }
 
+/* Wacom's last frame resets all values to 0, including x/y.
+   Skip over this. */
+if (prox_state == 0) {
+int v;
+if (valuator_mask_fetch(pEvdev->abs_vals, 0, ) && v == 0)
+valuator_mask_unset(pEvdev->abs_vals, 0);
+if (valuator_mask_fetch(pEvdev->abs_vals, 1, ) && v == 0)
+valuator_mask_unset(pEvdev->abs_vals, 1);
+}
+
 if ((prox_state && !pEvdev->in_proximity) ||
 (!prox_state && pEvdev->in_proximity))
 {
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH synaptics] eventcomm: if we get a read error other than EAGAIN, remove the fd

[Peter Hutterer]

Otherwise poll() keeps on triggering on our fd until udev gets around to
notifying the server that the device is in some state of deadness. Meanwhile,
the input thread is busy filling the log up with "Read error" messages. Great
way to test file systems and their ability to handle out of space scenarios
but otherwise a bit pointless. Those FS developers should write their own
tests instead of relying on the synaptics driver!

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 src/eventcomm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/eventcomm.c b/src/eventcomm.c
index c69cb66..2cd8704 100644
--- a/src/eventcomm.c
+++ b/src/eventcomm.c
@@ -557,6 +557,7 @@ SynapticsReadEvent(InputInfoPtr pInfo, struct input_event 
*ev)
 if (rc != -EAGAIN) {
 LogMessageVerbSigSafe(X_ERROR, 0, "%s: Read error %d\n", 
pInfo->name,
 errno);
+xf86RemoveEnabledDevice(pInfo);
 } else if (proto_data->read_flag == LIBEVDEV_READ_FLAG_SYNC) {
 proto_data->read_flag = LIBEVDEV_READ_FLAG_NORMAL;
 return SynapticsReadEvent(pInfo, ev);
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] meson: Fix module_dir configuration (v2)

[Peter Hutterer]

On Wed, May 02, 2018 at 12:54:26PM -0700, Aaron Plattner wrote:
> meson.build has code to set the module_dir variable to
> ${libdir}/xorg/modules if the module_dir option string is empty.
> However, this has several problems:
> 
> 1. The variable is only used for an unused @moduledir@ substitution in
>the man page. The rule for xorg-server.pc uses option('module_dir')
>directly instead.
> 2. The 'module_dir' option has a default value of 'xorg/modules' so the
>above rule doesn't do anything by default.
> 3. The xorg-server.pc rule uses ${exec_prefix}/option('module_dir'), so
>the effect of #2 is that the default moduledir is different between
>autoconf and meson. E.g. if ${prefix} is /X, then you get
> 
>  autoconf: moduledir=/X/lib/xorg/modules
>  meson:moduledir=/X/xorg/modules
> 
> Fix this by using the module_dir variable when generating xorg-server.pc, and 
> by
> using join_paths() to assign module_dir unconditionally.
> 
> v2: Keep the 'xorg/modules' default path, but use join_paths() 
> unconditionally (Thierry Reding)
> 
> Signed-off-by: Aaron Plattner <aplatt...@nvidia.com>

Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Cheers,
   Peter
> ---
>  meson.build   | 9 +++--
>  meson_options.txt | 2 +-
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 6571d08ebd38..59f19d5127fc 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -269,10 +269,7 @@ if log_dir == ''
>  log_dir = join_paths(get_option('prefix'), get_option('localstatedir'), 
> 'log')
>  endif
>  
> -module_dir = get_option('module_dir')
> -if module_dir == ''
> -module_dir = join_paths(get_option('libdir'), 'xorg/modules')
> -endif
> +module_dir = join_paths(get_option('libdir'), get_option('module_dir'))
>  
>  if glamor_option == 'auto'
>  build_glamor = build_xorg or build_xwayland
> @@ -534,7 +531,7 @@ manpage_config.set('XKB_DFLT_LAYOUT', 
> get_option('xkb_default_layout'))
>  manpage_config.set('XKB_DFLT_VARIANT', get_option('xkb_default_variant'))
>  manpage_config.set('XKB_DFLT_OPTIONS', get_option('xkb_default_options'))
>  manpage_config.set('bundle_id_prefix', '...')
> -manpage_config.set('modulepath', join_paths(get_option('prefix'), 
> module_dir))
> +manpage_config.set('modulepath', module_dir)
>  # wtf doesn't this work
>  # manpage_config.set('suid_wrapper_dir', join_paths(get_option('prefix'), 
> libexecdir))
>  manpage_config.set('suid_wrapper_dir', join_paths(get_option('prefix'), 
> 'libexec'))
> @@ -619,7 +616,7 @@ if build_xorg
>  sdkconfig.set('libdir', join_paths('${exec_prefix}', 
> get_option('libdir')))
>  sdkconfig.set('includedir', join_paths('${prefix}', 
> get_option('includedir')))
>  sdkconfig.set('datarootdir', join_paths('${prefix}', 
> get_option('datadir')))
> -sdkconfig.set('moduledir', join_paths('${exec_prefix}', 
> get_option('module_dir')))
> +sdkconfig.set('moduledir', join_paths('${exec_prefix}', module_dir))
>  sdkconfig.set('sdkdir', join_paths('${prefix}', 
> get_option('includedir'), 'xorg'))
>  sdkconfig.set('sysconfigdir', join_paths('${datarootdir}', 
> 'X11/xorg.conf.d'))
>  
> diff --git a/meson_options.txt b/meson_options.txt
> index a296838a15ea..86fca4668441 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -22,7 +22,7 @@ option('builder_string', type: 'string', description: 
> 'Additional builder string
>  
>  option('log_dir', type: 'string')
>  option('module_dir', type: 'string', value: 'xorg/modules',
> -   description: 'X.Org modules directory')
> +   description: 'X.Org modules directory (absolute or relative to the 
> directory specified by the libdir option)')
>  option('default_font_path', type: 'string')
>  
>  option('glx', type: 'boolean', value: true)
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] Use the libinput touch count to init the right number of touches

[Peter Hutterer]

Initial version by Johannes Pointner <h4nn35.w...@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 configure.ac   | 12 +++-
 src/xf86libinput.c | 10 +-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5892c5e..9c7174c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,11 +47,11 @@ XORG_DEFAULT_OPTIONS
 PKG_CHECK_MODULES(XORG, [xorg-server >= 1.10] xproto [inputproto >= 2.2])
 PKG_CHECK_MODULES(LIBINPUT, [libinput >= 1.4.901])
 
-AC_MSG_CHECKING([if libinput_device_config_accel_set_curve_point is available])
 OLD_LIBS=$LIBS
 OLD_CFLAGS=$CFLAGS
 LIBS="$LIBS $LIBINPUT_LIBS"
 CFLAGS="$CFLAGS $LIBINPUT_CFLAGS"
+AC_MSG_CHECKING([if libinput_device_config_accel_set_curve_point is available])
 AC_LINK_IFELSE(
[AC_LANG_PROGRAM([[#include ]],
 
[[libinput_device_config_accel_set_curve_point(NULL, 0, 0)]])],
@@ -61,6 +61,16 @@ AC_LINK_IFELSE(
 [libinput_have_custom_accel_curve=yes]],
[AC_MSG_RESULT([no])
 [libinput_have_custom_accel_curve=no]])
+AC_MSG_CHECKING([if libinput_device_touch_get_touch_count is available])
+AC_LINK_IFELSE(
+   [AC_LANG_PROGRAM([[#include ]],
+
[[libinput_device_touch_get_touch_count(NULL)]])],
+   [AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_LIBINPUT_TOUCH_COUNT, [1],
+  [libinput_device_touch_get_touch_count() is 
available])
+[libinput_have_touch_count=yes]],
+   [AC_MSG_RESULT([no])
+[libinput_have_touch_count=no]])
 LIBS=$OLD_LIBS
 CFLAGS=$OLD_CFLAGS
 
diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 4a1b9e6..180907e 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -1095,11 +1095,13 @@ xf86libinput_init_touch(InputInfoPtr pInfo)
 {
DeviceIntPtr dev = pInfo->dev;
struct xf86libinput *driver_data = pInfo->private;
+   struct libinput_device *device = driver_data->shared_device->device;
int min, max, res;
unsigned char btnmap[MAX_BUTTONS + 1];
Atom btnlabels[MAX_BUTTONS];
Atom axislabels[TOUCHPAD_NUM_AXES];
int nbuttons = 7;
+   int ntouches = TOUCH_MAX_SLOTS;
 
init_button_map(btnmap, ARRAY_SIZE(btnmap));
init_button_labels(btnlabels, ARRAY_SIZE(btnlabels));
@@ -1123,7 +1125,13 @@ xf86libinput_init_touch(InputInfoPtr pInfo)
xf86InitValuatorAxisStruct(dev, 1,
   
XIGetKnownProperty(AXIS_LABEL_PROP_ABS_MT_POSITION_Y),
   min, max, res * 1000, 0, res * 1000, 
Absolute);
-   InitTouchClassDeviceStruct(dev, TOUCH_MAX_SLOTS, XIDirectTouch, 2);
+
+#if HAVE_LIBINPUT_TOUCH_COUNT
+   ntouches = libinput_device_touch_get_touch_count(device);
+   if (ntouches == 0) /* unknown -  mtdev */
+   ntouches = TOUCH_MAX_SLOTS;
+#endif
+   InitTouchClassDeviceStruct(dev, ntouches, XIDirectTouch, 2);
 
 }
 
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xts] Add 'q' command line option to count subtests

[Peter Hutterer]

On Wed, Apr 25, 2018 at 03:58:07PM -0400, Adam Jackson wrote:
> At the moment piglit needs a copy of the test _source_ around, because
> it parses the .m files looking for >>ASSERTION to know how many subtests
> each executable contains. With this patch we can instead do:
> 
> datura:~/git/xts% xts5/Xlib4/*/XChangeWindowAttributes q
> 46
> 
> Sorry for the ad-hoc extern, but there's not a header for that
> declaration already. The code seems to also have a memory of a "reduced
> space" build where all the tests are linked into one giant binary; we
> don't support building that anyway, but this change would assuredly
> break it too.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>
but: any specific reason you don't just name it --count? it's just a strcmp
and would make things clearer

Cheers,
   Peter

> ---
>  src/tet3/tcm/dtcm.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/src/tet3/tcm/dtcm.c b/src/tet3/tcm/dtcm.c
> index 3d56e8d8..afb8c4eb 100644
> --- a/src/tet3/tcm/dtcm.c
> +++ b/src/tet3/tcm/dtcm.c
> @@ -295,6 +295,12 @@ char **argv;
>   if (!tcname)
>   tcname = tet_pname;
>  
> +if (argc > 1 && !strcmp(argv[1], "q")) {
> +extern int ntests;
> +printf("%d\n", ntests);
> +exit(0);
> +}
> +
>  #ifdef TET_LITE
>   /* open execution results file (do early, so tet_error() can use it) */
>   tet_openres(argv[0]);
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] animcur: Fix crash when removing a master device

[Peter Hutterer]

On Mon, Apr 23, 2018 at 03:21:14PM -0400, Adam Jackson wrote:
> Reproducer:
> 
> $ Xvfb -ac -noreset :1 &
> $ DISPLAY=:1 xinput create-master touch1
> $ DISPLAY=:1 xinput remove-master "touch1 pointer"
> 
> Bugzilla: https://bugs.freedesktop.org/105761
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Cheers,
   Peter

> ---
>  render/animcur.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/render/animcur.c b/render/animcur.c
> index 65327df655..ef27bda278 100644
> --- a/render/animcur.c
> +++ b/render/animcur.c
> @@ -155,7 +155,8 @@ AnimCurTimerNotify(OsTimerPtr timer, CARD32 now, void 
> *arg)
>  static void
>  AnimCurCancelTimer(DeviceIntPtr pDev)
>  {
> -CursorPtr cur = pDev->spriteInfo->sprite->current;
> +CursorPtr cur = pDev->spriteInfo->sprite ?
> +pDev->spriteInfo->sprite->current : NULL;
>  
>  if (IsAnimCur(cur))
>  TimerCancel(GetAnimCur(cur)->timer);
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] Implement the custom acceleration curve options

[Peter Hutterer]

One new property, and the existing accel profile gets extended to keep one
extra value. The new property libinput Accel Curve Points is a list of pairs
of points to be added to the acceleration curve.

libinput only supports adding points to the curve so we simply declare the
behavior as undefined when the curve is set multiple times. Also helps to
identify those that bother to read the man page before playing with random
driver values.

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
Note, the matching libinput patch is not yet on git master.

 configure.ac  |  17 
 include/libinput-properties.h |   8 ++
 man/libinput.man  |  53 +-
 src/xf86libinput.c| 227 +-
 4 files changed, 298 insertions(+), 7 deletions(-)

diff --git a/configure.ac b/configure.ac
index 34f2274..5892c5e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -47,6 +47,23 @@ XORG_DEFAULT_OPTIONS
 PKG_CHECK_MODULES(XORG, [xorg-server >= 1.10] xproto [inputproto >= 2.2])
 PKG_CHECK_MODULES(LIBINPUT, [libinput >= 1.4.901])
 
+AC_MSG_CHECKING([if libinput_device_config_accel_set_curve_point is available])
+OLD_LIBS=$LIBS
+OLD_CFLAGS=$CFLAGS
+LIBS="$LIBS $LIBINPUT_LIBS"
+CFLAGS="$CFLAGS $LIBINPUT_CFLAGS"
+AC_LINK_IFELSE(
+   [AC_LANG_PROGRAM([[#include ]],
+
[[libinput_device_config_accel_set_curve_point(NULL, 0, 0)]])],
+   [AC_MSG_RESULT([yes])
+AC_DEFINE(HAVE_LIBINPUT_CUSTOM_ACCEL_CURVE, [1],
+  [libinput_device_config_accel_set_curve_point() is 
available])
+[libinput_have_custom_accel_curve=yes]],
+   [AC_MSG_RESULT([no])
+[libinput_have_custom_accel_curve=no]])
+LIBS=$OLD_LIBS
+CFLAGS=$OLD_CFLAGS
+
 # Define a configure option for an alternate input module directory
 AC_ARG_WITH(xorg-module-dir,
 AC_HELP_STRING([--with-xorg-module-dir=DIR],
diff --git a/include/libinput-properties.h b/include/libinput-properties.h
index a701316..3169cfb 100644
--- a/include/libinput-properties.h
+++ b/include/libinput-properties.h
@@ -73,6 +73,14 @@
only one is enabled at a time at max */
 #define LIBINPUT_PROP_ACCEL_PROFILE_ENABLED "libinput Accel Profile Enabled"
 
+/* Pointer accel custom curve: FLOAT, n values for n>=0 && n%2 == 0, where
+   each pair of values are the x/y coordinates of the acceleration curve.
+   The exact behavior depends on the acceleration profile.
+
+   This property should be considered write-only, the value of the property may
+   not reflect the actual curve points used in libinput. */
+#define LIBINPUT_PROP_ACCEL_CURVE_POINTS "libinput Accel Curve Points"
+
 /* Natural scrolling: BOOL, 1 value */
 #define LIBINPUT_PROP_NATURAL_SCROLL "libinput Natural Scrolling Enabled"
 
diff --git a/man/libinput.man b/man/libinput.man
index dbf7dee..acb447d 100644
--- a/man/libinput.man
+++ b/man/libinput.man
@@ -45,11 +45,19 @@ are supported:
 Sets the pointer acceleration profile to the given profile. Permitted values
 are
 .BI adaptive,
-.BI flat.
+.BI flat,
+.BI device-speed-curve.
 Not all devices support this option or all profiles. If a profile is
 unsupported, the default profile for this device is used. For a description
 on the profiles and their behavior, see the libinput documentation.
 .TP 7
+.BI "Option \*qAccelCurvePoints\*q \*q" string \*q
+A string of space-separated pairs of floats, each pair value separated by a
+colon, i.e. the string looks like this "A:B C:D". These pairs represent the
+x/y value of a point on the acceleration curve. See
+.B CUSTOM POINTER ACCELERATION CURVES
+for details.
+.TP 7
 .BI "Option \*qAccelSpeed\*q \*q" float \*q
 Sets the pointer acceleration speed within the range [-1, 1]
 .TP 7
@@ -204,16 +212,26 @@ on the device. The following properties are provided by 
the
 driver.
 .TP 7
 .BI "libinput Accel Profiles Available"
-2 boolean values (8 bit, 0 or 1), in order "adaptive", "flat".
-Indicates which acceleration profiles are available on this device.
+3 boolean values (8 bit, 0 or 1), in order "adaptive", "flat",
+"device-speed-curve". Indicates which acceleration profiles are available on
+this device.
 .TP 7
 .BI "libinput Accel Profile Enabled"
-2 boolean values (8 bit, 0 or 1), in order "adaptive", "flat".
-Indicates which acceleration profile is currently enabled on this device.
+3 boolean values (8 bit, 0 or 1), in order "adaptive", "flat",
+"device-speed-curve". Indicates which acceleration profile is currently
+enabled on this device.
 .TP 7
 .BI "libinput Accel Speed"
 1 32-bit float value, defines the pointer speed. Value range -1, 1
 .TP 7
+.BI "libinput Accel Curve Points"
+n 32-bi

Re: [PATCH xserver] xwayland: Don't crash on WarpPointer(dest_w = None)

[Peter Hutterer]

On Thu, Apr 12, 2018 at 05:24:08PM -0400, Adam Jackson wrote:
> Turns out that's legal, and xts exercises it, and we crash:
> 
> Thread 1 "Xwayland" received signal SIGSEGV, Segmentation fault.
> dixGetPrivate (key=0x813660 , privates=0x20) at 
> ../../include/privates.h:122
> 122   return (char *) (*privates) + key->offset;
> (gdb) bt
> #0  dixGetPrivate (key=0x813660 , privates=0x20) 
> at ../../include/privates.h:122
> #1  dixLookupPrivate (key=0x813660 , 
> privates=0x20) at ../../include/privates.h:166
> #2  xwl_window_of_top (window=0x0) at xwayland.c:128
> #3  xwl_cursor_warped_to (device=, screen=0x268b6e0, 
> client=, window=0x0, sprite=0x300bb30,
> x=2400, y=1350) at xwayland.c:292
> #4  0x005622ec in ProcWarpPointer (client=0x32755d0) at 
> events.c:3618
> 
> In this case, x/y are the screen-space coordinates where the pointer
> ends up, and we need to look up the (X) window there.
> 
> Signed-off-by: Adam Jackson <a...@redhat.com>

Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Cheers,
   Peter

> ---
>  hw/xwayland/xwayland.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index e65d8b7e77..dd074c3415 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -289,6 +289,9 @@ xwl_cursor_warped_to(DeviceIntPtr device,
>  if (!xwl_seat)
>  xwl_seat = xwl_screen_get_default_seat(xwl_screen);
>  
> +if (!window)
> +window = XYToWindow(sprite, x, y);
> +
>  xwl_window = xwl_window_of_top(window);
>  if (!xwl_window && xwl_seat->focus_window) {
>  focus = xwl_seat->focus_window->window;
> -- 
> 2.17.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] sdksyms: Skip empty symbols

[Peter Hutterer]

On Wed, Apr 11, 2018 at 03:39:33PM -0400, Adam Jackson wrote:
> Apparently on NetBSD we can hit failures like this:
> 
> sdksyms.c:1773:15: error: expected expression before ',' token
>  (void *) &,  /* 
> ../../dri3/dri3.h:110 */
> 
> I've been unable to reproduce that locally (even in a NetBSD vm), but
> an obvious workaround might be to just notice empty symbol names and
> ignore them rather than emit invalid C code.
> 
> Cc: Thomas Klausner <w...@netbsd.org>
> Signed-off-by: Adam Jackson <a...@redhat.com>
> ---
>  hw/xfree86/sdksyms.sh | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
> index d927fcd165..fc171d9188 100755
> --- a/hw/xfree86/sdksyms.sh
> +++ b/hw/xfree86/sdksyms.sh
> @@ -415,7 +415,8 @@ BEGIN {
>   sub(/[^a-zA-Z0-9_].*/, "", symbol);
>  
>   #print;
> - printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, line);
> + if (symbol != "")

my awk skills are non-existent but shouldn't this be $symbol? The condition a 
few
lines above uses $n == "" instead of n == ""

with that change, Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Cheers,
   Peter

> + printf("(void *) &%-50s /* %s:%s */\n", symbol ",", header, 
> line);
>  }
>  }
>  
> -- 
> 2.17.0
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] dix: always send focus event on grab change

[Peter Hutterer]

On Mon, Apr 09, 2018 at 02:35:30PM +0200, Samuel Thibault wrote:
> Focus events are useless when 'from' and 'to' are the same.  But when
> this is the result of a (Un)GrabKeyboard request, we should always send
> them, including when the window manager had previously used XSetInputFocus
> to specify the focus on a window which happens to be now taking a grab.
> 
> This is notably needed for window manager using XI to always get keyboard
> events even during grabs, so they can determine exactly when grabbing is
> active.
> 
> Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>

good catch, thanks.
Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Ajax - feel free to take this one or wait for 1.20.1. It should be safe but
there could be subtle bugs. Proably not any worse than having this broken
for the last 10 years.

Cheers,
   Peter

> ---
>  dix/enterleave.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/dix/enterleave.c b/dix/enterleave.c
> index 1b341f2de..a2f625bc9 100644
> --- a/dix/enterleave.c
> +++ b/dix/enterleave.c
> @@ -1562,7 +1562,7 @@ DoFocusEvents(DeviceIntPtr pDev, WindowPtr from, 
> WindowPtr to, int mode)
>  if (!IsKeyboardDevice(pDev))
>  return;
>  
> -if (from == to)
> +if (from == to && mode != NotifyGrab && mode != NotifyUngrab)
>  return;
>  
>  CoreFocusEvents(pDev, from, to, mode);
> -- 
> 2.16.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 2/8] dmx: Fix some snprintf warnings.

[Peter Hutterer]

On Thu, Apr 05, 2018 at 01:13:55PM -0400, Adam Jackson wrote:
> snprintf doesn't terminate the string if it truncates, so things like
> this are lurking crashers:

it doesn't? which platforms is that on? Apparently windows, from a quick
google but that's about it, right?

Cheers,
   Peter


> 
> ../hw/dmx/dmxprop.c: In function ‘dmxPropertyIdentifier.part.0’:
> ../hw/dmx/dmxprop.c:94:36: warning: ‘%s’ directive output may be truncated 
> writing up to 255 bytes into a region of size 123 [-Wformat-truncation=]
>  snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
> ^~ 
> ../hw/dmx/dmxprop.c:94:5: note: ‘snprintf’ output 7 or more bytes (assuming 
> 262) into a destination of size 128
>  snprintf(buf, sizeof(buf), "%s:%s:%s", DMX_IDENT, hostname, display);
>  ^~~~
> ../hw/dmx/dmxprop.c: In function ‘dmxPropertyWindow’:
> ../hw/dmx/dmxprop.c:372:36: warning: ‘%d’ directive output may be truncated 
> writing between 1 and 11 bytes into a region of size between 0 and 127 
> [-Wformat-truncation=]
>  snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
> ^~
> ../hw/dmx/dmxprop.c:372:5: note: ‘snprintf’ output between 3 and 140 bytes 
> into a destination of size 128
>  snprintf(buf, sizeof(buf), "%s,%d", id, dmxScreen->index);
>  ^
> 
> We could be more precise about termination, but meh.
> 
> Signed-off-by: Adam Jackson 
> ---
>  hw/dmx/dmxprop.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/dmx/dmxprop.c b/hw/dmx/dmxprop.c
> index 4c85268b79..7dfa04af5a 100644
> --- a/hw/dmx/dmxprop.c
> +++ b/hw/dmx/dmxprop.c
> @@ -84,7 +84,7 @@ dmxPropertyIdentifier(void)
>  /* RATS: These buffers are only used in
>   * length-limited calls. */
>  char hostname[256];
> -static char buf[128];
> +static char buf[512];
>  static int initialized = 0;
>  
>  if (initialized++)
> @@ -346,7 +346,7 @@ dmxPropertyWindow(DMXScreenInfo * dmxScreen)
>  Display *dpy = dmxScreen->beDisplay;
>  Window win = dmxScreen->scrnWin;
>  DMXScreenInfo *other;
> -char buf[128];  /* RATS: only used with snprintf */
> +char buf[1024];  /* RATS: only used with snprintf */
>  
>  if (!dpy)
>  return; /* FIXME: What should be done here if Xdmx 
> is started
> -- 
> 2.16.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] xfree86: drop KDSKBMUTE handling

[Peter Hutterer]

This was never merged upstream. It was a Fedora kernel patch but dropped from
Fedora in 2013 with kernel 3.12.

The reason for the KDSKBMUTE proposal has been fixed in systemd in Feb 2013,
systemd 198.
https://lists.freedesktop.org/archives/systemd-devel/2013-February/008795.html

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 hw/xfree86/os-support/linux/lnx_init.c | 26 --
 1 file changed, 8 insertions(+), 18 deletions(-)

diff --git a/hw/xfree86/os-support/linux/lnx_init.c 
b/hw/xfree86/os-support/linux/lnx_init.c
index 9e5ddcd50..a2464 100644
--- a/hw/xfree86/os-support/linux/lnx_init.c
+++ b/hw/xfree86/os-support/linux/lnx_init.c
@@ -46,10 +46,6 @@
 #define K_OFF 0x4
 #endif
 
-#ifndef KDSKBMUTE
-#define KDSKBMUTE 0x4B51
-#endif
-
 static Bool KeepTty = FALSE;
 static int activeVT = -1;
 
@@ -262,23 +258,18 @@ xf86OpenConsole(void)
 tcgetattr(xf86Info.consoleFd, _attr);
 SYSCALL(ioctl(xf86Info.consoleFd, KDGKBMODE, _mode));
 
-/* disable kernel special keys and buffering, new style */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMUTE, 1));
+/* disable kernel special keys and buffering */
+SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_OFF));
 if (ret < 0)
 {
-/* disable kernel special keys and buffering, old style */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_OFF));
+/* fine, just disable special keys */
+SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW));
 if (ret < 0)
-{
-/* fine, just disable special keys */
-SYSCALL(ret = ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW));
-if (ret < 0)
-FatalError("xf86OpenConsole: KDSKBMODE K_RAW failed 
%s\n",
-   strerror(errno));
+FatalError("xf86OpenConsole: KDSKBMODE K_RAW failed %s\n",
+   strerror(errno));
 
-/* ... and drain events, else the kernel gets angry */
-xf86SetConsoleHandler(drain_console, NULL);
-}
+/* ... and drain events, else the kernel gets angry */
+xf86SetConsoleHandler(drain_console, NULL);
 }
 
 nTty = tty_attr;
@@ -327,7 +318,6 @@ xf86CloseConsole(void)
 xf86Msg(X_WARNING, "xf86CloseConsole: KDSETMODE failed: %s\n",
 strerror(errno));
 
-SYSCALL(ioctl(xf86Info.consoleFd, KDSKBMUTE, 0));
 SYSCALL(ioctl(xf86Info.consoleFd, KDSKBMODE, tty_mode));
 tcsetattr(xf86Info.consoleFd, TCSANOW, _attr);
 
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xfree86: Restore newline before "X Protocol Version" string

[Peter Hutterer]

On Mon, Apr 02, 2018 at 03:04:08PM -0700, Aaron Plattner wrote:
> The newline before the protocl version got lost in commit
> 6cbefc3e0a33b380c147c533914437c7798d9b93. Prior to that commit, the
> release date printed a newline at the end:
> 
>  X.Org X Server 1.19.6
>  Release Date: 2017-12-20
>  X Protocol Version 11, Revision 0
>  Build Operating System: Linux 4.14.12-1-ARCH x86_64
> 
> Now, that string gets run together with the version:
> 
>  X.Org X Server 1.19.99.903 (1.20.0 RC 3)X Protocol Version 11, Revision 0
>  Build Operating System: Linux
> 
> Since the version string printing has a variety of #ifdefs in it, just
> add the newline to the begining of the protocol version string.
> 
> Signed-off-by: Aaron Plattner 

remote: Updating patchwork state for 
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #214323 updated using rev 
574069c2912893a9b9fd3d701eb3ad4784e31553.
remote: I: 1 patch(es) updated to state Accepted.
To git+ssh://git.freedesktop.org/git/xorg/xserver
   df6cbf7a2..574069c29  master -> master

Cheers,
   Peter

> ---
>  hw/xfree86/common/xf86Init.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/common/xf86Init.c b/hw/xfree86/common/xf86Init.c
> index ea42ec946167..3c5cc7097c49 100644
> --- a/hw/xfree86/common/xf86Init.c
> +++ b/hw/xfree86/common/xf86Init.c
> @@ -165,7 +165,7 @@ xf86PrintBanner(void)
>  #ifdef XORG_CUSTOM_VERSION
>  xf86ErrorFVerb(0, " (%s)", XORG_CUSTOM_VERSION);
>  #endif
> -xf86ErrorFVerb(0, "X Protocol Version %d, Revision %d\n",
> +xf86ErrorFVerb(0, "\nX Protocol Version %d, Revision %d\n",
> X_PROTOCOL, X_PROTOCOL_REVISION);
>  xf86ErrorFVerb(0, "Build Operating System: %s %s\n", OSNAME, OSVENDOR);
>  #ifdef HAS_UTSNAME
> -- 
> 2.16.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] man: note that we don't do /dev/input/by-id or /dev/input/by-path

[Peter Hutterer]

For logind-setups we need to match the path libinput wants to open with the
Option Device path that the device has so we know when to return the
server-fd. This doesn't work for by-id or by-path because libinput resolves
those (through udev) to the actual eventX node so our paths look different
when they are the same device.

This could be fixed but since this is easy enough to work around with a
InputClass section and rather a niche case, it's not really worth the effort.

https://bugs.freedesktop.org/show_bug.cgi?id=105562

Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
---
 man/libinput.man | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/man/libinput.man b/man/libinput.man
index 2725390..ec0f439 100644
--- a/man/libinput.man
+++ b/man/libinput.man
@@ -381,6 +381,12 @@ it takes left-handed-ness into account.
 .TP
 This feature is provided by this driver, not by libinput.
 
+.SH BUGS
+This driver does not work with \fBOption \*qDevice\*q\fR set to an event
+node in \fI/dev/input/by-id\fR and \fI/dev/input/by-path\fR. This can be
+usually be worked by using \fBSection \*qInputClass\*q\fR with an
+appropriate \fBMatch*\fR statement in the __xconfigfile__(__filemansuffix__).
+
 .SH AUTHORS
 Peter Hutterer
 .SH "SEE ALSO"
-- 
2.14.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xkb: XkbSetMap on the lastSlave needs to change the master

[Peter Hutterer]

On Sat, Mar 03, 2018 at 01:41:12AM +, Samir Benmendil wrote:
> The layout needs to be set on the master too if the layout is changed on
> the device that was last used by the master.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=85256
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=91571
> 
> Signed-off-by: Samir Benmendil 
> ---
>  xkb/xkb.c | 26 +-
>  1 file changed, 25 insertions(+), 1 deletion(-)
> 
> diff --git a/xkb/xkb.c b/xkb/xkb.c
> index 678f82368..12460034b 100644
> --- a/xkb/xkb.c
> +++ b/xkb/xkb.c
> @@ -2626,6 +2626,8 @@ ProcXkbSetMap(ClientPtr client)
>  if (rc != Success)
>  return rc;
>  
> +DeviceIntPtr master = GetMaster(dev, MASTER_KEYBOARD);
> +
>  if (stuff->deviceSpec == XkbUseCoreKbd) {
>  DeviceIntPtr other;
>  
> @@ -2641,9 +2643,21 @@ ProcXkbSetMap(ClientPtr client)
>  }
>  }
>  }
> +} else {
> +DeviceIntPtr other;
> +
> +for (other = inputInfo.devices; other; other = other->next) {
> +if (other != dev && GetMaster(other, MASTER_KEYBOARD) != dev &&
> +(other != master || dev != master->lastSlave))
> +continue;

wouldn't this be sufficient here:
if (master && master->lastSlave == dev) {
rc = _XkbSetMapChecks(client, other, stuff, tmp);
...
}

there can only be one master keyboard per slave and it can only have one
lastSlave.

> +
> +rc = _XkbSetMapChecks(client, other, stuff, tmp);
> +if (rc != Success)
> +return rc;
> +}
>  }
>  
> -/* We know now that we will succed with the SetMap. In theory anyway. */
> +/* We know now that we will succeed with the SetMap. In theory anyway. */
>  rc = _XkbSetMap(client, dev, stuff, tmp);
>  if (rc != Success)
>  return rc;
> @@ -2664,6 +2678,16 @@ ProcXkbSetMap(ClientPtr client)
> sync. */
>  }
>  }
> +} else {
> +DeviceIntPtr other;
> +
> +for (other = inputInfo.devices; other; other = other->next) {
> +if (other != dev && GetMaster(other, MASTER_KEYBOARD) != dev &&
> +(other != master || dev != master->lastSlave))
> +continue;
> +
> +_XkbSetMap(client, other, stuff, tmp); //ignore rc

same as above

Cheers,
   Peter
 
> +}
>  }
>  
>  return Success;
> -- 
> 2.14.2
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput 3/3] Apply the capabilities checks on subdevices when applying the config

[Peter Hutterer]

Properties are initialized on the correct devices only but on resume we'd just
blindly apply the config from our device. Depending on the resume order, this
would mean we'd apply a previously set config with a default config.

Example:
* pointer device with keyboard subdevice
* pointer device exports natural scrolling, keyboard device does not and
  remains at default (off)
* client enables natural scrolling on the pointer device
* VT switch away, VT switch back
* pointer device gets enabled first, enables natural scrolling on the
  libinput device
* keyboard device gets enabled second, resets to the default value

Reported-by: Yuxuan Shui <yshu...@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
Tested-by: Yuxuan Shui <yshu...@gmail.com>
---
 src/xf86libinput.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index cb37dab..83ab75d 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -505,6 +505,9 @@ LibinputApplyConfigNaturalScroll(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_scroll_has_natural_scroll(device) &&
libinput_device_config_scroll_set_natural_scroll_enabled(device,
 
driver_data->options.natural_scrolling) != LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -520,6 +523,9 @@ LibinputApplyConfigAccel(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_accel_is_available(device) &&
libinput_device_config_accel_set_speed(device,
   driver_data->options.speed) 
!= LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -556,6 +562,9 @@ LibinputApplyConfigTap(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_tap_get_finger_count(device) > 0 &&
libinput_device_config_tap_set_enabled(device,
   
driver_data->options.tapping) != LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -600,6 +609,9 @@ LibinputApplyConfigCalibration(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_TOUCH|CAP_TABLET))
+   return;
+
if (libinput_device_config_calibration_has_matrix(device) &&
libinput_device_config_calibration_set_matrix(device,
  
driver_data->options.matrix) != LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -620,6 +632,9 @@ LibinputApplyConfigLeftHanded(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER|CAP_TABLET))
+   return;
+
if (libinput_device_config_left_handed_is_available(device) &&
libinput_device_config_left_handed_set(device,
   
driver_data->options.left_handed) != LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -635,6 +650,9 @@ LibinputApplyConfigScrollMethod(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_scroll_set_method(device,
 
driver_data->options.scroll_method) != LIBINPUT_CONFIG_STATUS_SUCCESS) {
const char *method;
@@ -671,6 +689,9 @@ LibinputApplyConfigClickMethod(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_click_set_method(device,

driver_data->options.click_method) != LIBINPUT_CONFIG_STATUS_SUCCESS) {
const char *method;
@@ -696,6 +717,9 @@ LibinputApplyConfigMiddleEmulation(DeviceIntPtr dev,
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
 
+   if (!subdevice_has_capabilities(dev, CAP_POINTER))
+   return;
+
if (libinput_device_config_middle_emulation_is_available(device) &&
libinput_device_config_middle_emulation_set_enabled(device,

driver_data->options.middle_emulation) != LIBINPUT_CONFIG_STATUS_SUCCESS)
@@ -711,6 +735,9 @@ LibinputApplyConfigDisableWhileTyping(DeviceIntPtr dev,
 {
InputInfoPtr p

[PATCH xf86-input-libinput 2/3] Split LibinputDeviceApplyConfig into helper functions

[Peter Hutterer]

No functional changes
---
 src/xf86libinput.c | 110 ++---
 1 file changed, 105 insertions(+), 5 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index c5612a8..cb37dab 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -483,13 +483,12 @@ LibinputSetProperty(DeviceIntPtr dev, Atom atom, 
XIPropertyValuePtr val,
 static void
 LibinputInitProperty(DeviceIntPtr dev);
 
-static inline void
-LibinputApplyConfig(DeviceIntPtr dev)
+static void
+LibinputApplyConfigSendEvents(DeviceIntPtr dev,
+ struct xf86libinput *driver_data,
+ struct libinput_device *device)
 {
InputInfoPtr pInfo = dev->public.devicePrivate;
-   struct xf86libinput *driver_data = pInfo->private;
-   struct libinput_device *device = driver_data->shared_device->device;
-   unsigned int scroll_button;
 
if (libinput_device_config_send_events_get_modes(device) != 
LIBINPUT_CONFIG_SEND_EVENTS_ENABLED &&
libinput_device_config_send_events_set_mode(device,
@@ -497,6 +496,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
xf86IDrvMsg(pInfo, X_ERROR,
"Failed to set SendEventsMode %u\n",
driver_data->options.sendevents);
+}
+
+static void
+LibinputApplyConfigNaturalScroll(DeviceIntPtr dev,
+struct xf86libinput *driver_data,
+struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_scroll_has_natural_scroll(device) &&
libinput_device_config_scroll_set_natural_scroll_enabled(device,
@@ -504,6 +511,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
xf86IDrvMsg(pInfo, X_ERROR,
"Failed to set NaturalScrolling to %d\n",
driver_data->options.natural_scrolling);
+}
+
+static void
+LibinputApplyConfigAccel(DeviceIntPtr dev,
+struct xf86libinput *driver_data,
+struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_accel_is_available(device) &&
libinput_device_config_accel_set_speed(device,
@@ -532,6 +547,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
}
xf86IDrvMsg(pInfo, X_ERROR, "Failed to set profile %s\n", 
profile);
}
+}
+
+static inline void
+LibinputApplyConfigTap(DeviceIntPtr dev,
+  struct xf86libinput *driver_data,
+  struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_tap_get_finger_count(device) > 0 &&
libinput_device_config_tap_set_enabled(device,
@@ -568,6 +591,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
xf86IDrvMsg(pInfo, X_ERROR,
"Failed to set Tapping Drag to %d\n",
driver_data->options.tap_drag);
+}
+
+static void
+LibinputApplyConfigCalibration(DeviceIntPtr dev,
+  struct xf86libinput *driver_data,
+  struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_calibration_has_matrix(device) &&
libinput_device_config_calibration_set_matrix(device,
@@ -580,6 +611,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
driver_data->options.matrix[4], 
driver_data->options.matrix[5],
driver_data->options.matrix[6], 
driver_data->options.matrix[7],
driver_data->options.matrix[8]);
+}
+
+static void
+LibinputApplyConfigLeftHanded(DeviceIntPtr dev,
+  struct xf86libinput *driver_data,
+  struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_left_handed_is_available(device) &&
libinput_device_config_left_handed_set(device,
@@ -587,6 +626,14 @@ LibinputApplyConfig(DeviceIntPtr dev)
xf86IDrvMsg(pInfo, X_ERROR,
"Failed to set LeftHanded to %d\n",
driver_data->options.left_handed);
+}
+
+static void
+LibinputApplyConfigScrollMethod(DeviceIntPtr dev,
+   struct xf86libinput *driver_data,
+   struct libinput_device *device)
+{
+   InputInfoPtr pInfo = dev->public.devicePrivate;
 
if (libinput_device_config_scroll_set_method(device,
 
driver_data->options.scroll_method) != LIBINPUT_CONFIG_STATUS_SUCCESS) {
@@ -607,12 +654,22 @@ LibinputApplyConfig(DeviceIntPtr dev)
}
 
if