Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Mon, Feb 05, 2024 at 10:33:52AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 05, 2024 at 10:34:13AM +1000, Peter Hutterer wrote:
> > > And even before that, things were already only limping along. That was
> > > happening for over a decade and in that timeframe *nobody* has wanted
> > > to step up and work on it. Wayland is the future because otherwise we
> > > have no graphics future, as things currently stand.
> > 
> > It also doesn't help that the "it's the same people working on X and
> > Wayland" argument means that, absent significant breakthroughs in
> > space-time research, we can work on one or the other, not both.
> > Something's got to give.
> 
> We could also switch to a 4-day week, with 20h shifts ;)

"if 24h in a day isn't enough, work at night"

Uncredited because I'm not sure the person I got this from (in jest)
really wants the credit ;)

Cheers,
  Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Fri, Feb 02, 2024 at 11:08:15AM +, Neal Gompa wrote:
> On Fri, Feb 2, 2024 at 10:47 AM Peter Hutterer  
> wrote:
> >
> > On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote:
> > > On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> > > > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> > > > 
> > > >
> > > > > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > > > > want
> > > > > drop X11 and force user to use wayland .
> > > >
> > > >
> > > > Looking from the side I wonder If its the SIG or more the
> > > > circumstances
> > > > that everything is in a forward flow and the SIG is facing it. So, if
> > > > the best time was not two or one year ago, and obviously also not
> > > > now.
> > > > When then? The fact is that there must be a point in time when the
> > > > display server takes an evolution step forward.
> > > >
> > > > Pressure in such transition helps to get forward, so I understand the
> > > > SIGs POV. Albeit, from the practical POV there are some issue and
> > > > therefore X11 is still the place to be.
> > > >
> > > > Maybe some elaboration should be done about the current state of X11
> > > > vs
> > > > Wayland (is it just nvidia?) and a timeframe calculation to have a
> > > > resolution. Maybe it won't look so bad then and a interim solution is
> > > > then more acceptable.
> > >
> > >
> > > I have an obvious answer is when the authors decide, in this case Xorg,
> > > when Xorg decides that it will stop supporting X11, like happened to
> > > Python2 or PHP5 and 7 or Gnome
> >
> > X.org (the ppl doing X development) doesn't work that way, there won't
> > be an official "we're no longer supporting this". More likely
> > development will languish (except for Xwayland) and actual Xorg releases
> > will be few and far in between, at unpredictable cadence and subject to
> > someone wanting to do it.
> >
> > The last Xorg release (21.0) from the master branch was in Oct 2021. The
> > only reason that one happened was because Povilas (who wanted a new
> > feature in X) stepped up and did the work of collecting the MRs and
> > doing the release maintainership. Every 21.x release since has been
> > backports and, especially more recently, a huge percentage are CVE fixes.
> >
> > Fedora still ships the previous release, server 1.20.x, which was
> > originally released from git master in 2018, the 1.20.14 version we're
> > on (excluding fixes and CVEs) is from Dec 2021.
> >
> > Xwayland on the other hand (which lives in the same git repo) continues
> > on its merry way with the 23.2 series branched as recently as last
> > August. But an Xwayland release does not include Xorg because, well,
> > there is little motivation to do more Xorg releases.
> >
> > When it comes down to it it "just" needs someone (trustworthy enough) to
> > step up and do them. Whether the releases get picked up immediately like in
> > the olden days is a different matter. But I doubt there'll be an X.org
> > statement of "we no longer support Xorg" anytime soon, even though that
> > is, to some extent functionally already true.
> >
> 
> And even before that, things were already only limping along. That was
> happening for over a decade and in that timeframe *nobody* has wanted
> to step up and work on it. Wayland is the future because otherwise we
> have no graphics future, as things currently stand.

It also doesn't help that the "it's the same people working on X and
Wayland" argument means that, absent significant breakthroughs in
space-time research, we can work on one or the other, not both.
Something's got to give.

Cheers,
  Peter


> 
> This is why *every* graphical environment is *finally* working on
> their Wayland environments if they have any development resources at
> all. Last year, we had Cinnamon release its own experimental Wayland
> session with v6.0. Budgie is working on replacing X11 with Wayland
> this year. LXQt will be on Wayland with v2. Xfce is working on the
> same for v4.20. MATE is looking at Wayfire after previously looking at
> Mirco for Wayland. Pantheon has been working on it for over a year now
> and has an experimental session.
> 
> Everyone is making a path to Wayland a priority because finally enough
> is done so that they can.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Peter Hutterer]

On Thu, Feb 01, 2024 at 03:40:24PM +, Sérgio Basto wrote:
> On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> > Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> > 
> > 
> > > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > > want
> > > drop X11 and force user to use wayland .
> > 
> > 
> > Looking from the side I wonder If its the SIG or more the
> > circumstances
> > that everything is in a forward flow and the SIG is facing it. So, if
> > the best time was not two or one year ago, and obviously also not
> > now.
> > When then? The fact is that there must be a point in time when the 
> > display server takes an evolution step forward.
> > 
> > Pressure in such transition helps to get forward, so I understand the
> > SIGs POV. Albeit, from the practical POV there are some issue and 
> > therefore X11 is still the place to be.
> > 
> > Maybe some elaboration should be done about the current state of X11
> > vs
> > Wayland (is it just nvidia?) and a timeframe calculation to have a 
> > resolution. Maybe it won't look so bad then and a interim solution is
> > then more acceptable.
> 
> 
> I have an obvious answer is when the authors decide, in this case Xorg,
> when Xorg decides that it will stop supporting X11, like happened to
> Python2 or PHP5 and 7 or Gnome 

X.org (the ppl doing X development) doesn't work that way, there won't
be an official "we're no longer supporting this". More likely
development will languish (except for Xwayland) and actual Xorg releases
will be few and far in between, at unpredictable cadence and subject to
someone wanting to do it.

The last Xorg release (21.0) from the master branch was in Oct 2021. The
only reason that one happened was because Povilas (who wanted a new
feature in X) stepped up and did the work of collecting the MRs and
doing the release maintainership. Every 21.x release since has been
backports and, especially more recently, a huge percentage are CVE fixes.

Fedora still ships the previous release, server 1.20.x, which was
originally released from git master in 2018, the 1.20.14 version we're
on (excluding fixes and CVEs) is from Dec 2021.

Xwayland on the other hand (which lives in the same git repo) continues
on its merry way with the 23.2 series branched as recently as last
August. But an Xwayland release does not include Xorg because, well,
there is little motivation to do more Xorg releases. 

When it comes down to it it "just" needs someone (trustworthy enough) to
step up and do them. Whether the releases get picked up immediately like in
the olden days is a different matter. But I doubt there'll be an X.org
statement of "we no longer support Xorg" anytime soon, even though that
is, to some extent functionally already true.

Cheers,
  Peter


> 
> In fact, it is something I've been thinking about, IMHO, downstream
> shouldn't decide when software is deprecated or not like KDE and Red
> HAt did , it's weird to me [1], although in RHEL we could have the
> packages via EPEL, I think, and RHEL 10 is only in a year and a half 
> 
> 
> [1]
> https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_deprecated_and_will_remove/
> 
> 
> > --
> > Leon
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> -- 
> Sérgio M. B.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Turning a XImage * into a Drawable for use with XRenderCreatePicture

[Peter Hutterer]

On Thu, Jan 04, 2024 at 06:27:01PM +0100, Florian Weimer wrote:
> The pcb-rnd package contains a call:
> 
> XRenderCreatePicture(display, lpm->img_scaled, 
> XRenderFindVisualFormat(display, DefaultVisual(display, screen)), 0, 0);
> 
> The issue here is that lpm->img_scaled is an XImage *, but
> XRenderCreatePicture expected a Drawable as its second argument.
> 
> Any idea how to turn an XImage into a Drawable?

After digging through the Xlib sources a bit: an XImage is a
Xlib-specific struct that abstracts some manipulation functions. Unlike
a Drawable which exists on the protocol. You don't do anything with an
XImage except eventually rendering it to a Drawable.

So in this case - I guess look for where the lpm->img_scale is used on a
drawable and assume that's the drawable you want to use for the XRender
call. Which may or may not be lpm->pm_scaled in this case, I don't know
what the code does but it looks like that's the drawable the image
renders to.

> Not sure how this currently works, but GCC 14 refuse to compile this, as
> a C type error (using a pointer as an integer).

It cannot currently work. From XRenderCreatePicture() [1]:
  req->drawable = (CARD32) drawable;

which means that (parts of) the pointer value is sent to the server as
XID and the server should return BadDrawable unless you're really
(un)lucky with your pointer value.

Cheers,
  Peter

[1] 
https://gitlab.freedesktop.org/xorg/lib/libxrender/-/blob/master/src/Picture.c?ref_type=heads#L91
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaning piper

[Peter Hutterer]

I've orphaned the piper package. This is the GTK GUI to interface with
the libratbag daemon to configure programmable mice. It's up for grabs
now if you want it, first come, first serve and so on.

My personal take is that this should be flatpak only but who am I to
stand in the way of a motivated packager :)

Cheers,
  Peter

PS: if you *are* motivated, Piper desparately needs upstream maintainers
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: HaveIBeenPwned database in Fedora somewhere?

[Peter Hutterer]

On Tue, Mar 21, 2023 at 02:28:08PM +0100, Pavel Raiskup wrote:
> Hello all!
> 
> Do we have HaveIBeenPwned database of hashes somewhere in Fedora, as a
> file or service (regularly updated)?  I'd prefer checking my passwords
> manually, without actually giving the passwords to the
> https://haveibeenpwned.com service.  Speaking of that, I really dislike
> that the service takes the real passwords on it's input.
> 
> I seem I was able to reproduce the steps-to-download (currently
> downloading):
> https://github.com/HaveIBeenPwned/PwnedPasswordsDownloader
> But that will take quite some time...
> 
> Has anyone planed to at least package that dotnet utility?  How do you
> do this?

On https://haveibeenpwned.com/Passwords there's a link to
the explanation on how it works:
https://www.troyhunt.com/ive-just-launched-pwned-passwords-version-2/#cloudflareprivacyandkanonymity

Summary: it hashes the password, submits the first 5 letters and then 
compares the rest of the hash against the returned set of possible matches.
If you don't trust the website, you can do this yourself in Python with 
a few lines of code:

```
#!/usr/bin/env python3
import requests
import hashlib 

pwd="P@ssw0rd" 
myhash = hashlib.sha1(pwd.encode("utf8")).hexdigest() 
r = requests.get(f"https://api.pwnedpasswords.com/range/{myhash[:5]};)
for hash in r.text.split('\r\n'):
  if hash.startswith(myhash[5:].upper()):
print(f"Compromised: {myhash[:5].upper()}{hash}")
```

Creating a CLI for this should be trivial, packaging it too :)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Fri, Jan 06, 2023 at 11:13:14AM +1000, Peter Hutterer wrote:
> On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote:
> > On Thu, 5 Jan 2023 at 08:20, David Cantrell  wrote:
> > 
> > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote:
> > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote:
> > > > [...]
> > > > > > So I guess this means no remoting into ppc64 or s390x machines from
> > > > > > x86_64 or ppc64le machines without a configuration tweak?
> > > > >
> > > > > We don't have ppc64 builds anymore and I don't know the last release
> > > we had
> > > > > that was ppc64, but it was a long time ago now.  All current POWER
> > > systems are
> > > > > ppc64le.
> > > > >
> > > > > And everything else we have as primary or alternative architectures is
> > > little
> > > > > endian, except s390x.  I do view this as a risk for s390x because of
> > > all the
> > > > > architectures we build for, this one is the most difficult to use
> > > graphically.
> > > > > Exporting your display is still the convenient method for this
> > > platform.
> > > > >
> > > > > Given that this change proposal affects default behavior, I don't see 
> > > > > a
> > > > > problem with it.  s390x users can drop the configuration change in
> > > xorg.conf.d
> > > > > to regain the functionality.  If that can be conditionally enabled for
> > > s390x
> > > > > at package build time, that might make things easier (but wouldn't you
> > > need to
> > > > > make the change on both the s390x host and your non-s390x
> > > workstation?).
> > > >
> > > > The X protocol works that the first byte of the connection request is a
> > > > either 'l' or 'B', telling the server that the client is little or Big
> > > > endian. The client has no information on the server's endianess.
> > > >
> > > > This means the configuration needs to be done wherever your X server
> > > > runs, so the (little-endian) thing you're sitting in front of. Which is
> > > > also why compile-time defaults are difficult, at compile time we cannot
> > > > know that eventually you may want to connect from an s390x.
> > >
> > > Reasonable.  The runtime configuration change I can make locally to allow
> > > me
> > > to run X programs on an s390x and display them locally is sufficient for
> > > me.
> > >
> > 
> > Wasn't there a concern that you can do this if you are running a desktop
> > with X, but if you are using Xwayland it isn't easy (or maybe possible) as
> > the configuration to do that was either hardcoded or not fully documented
> > on how to do that?
> > 
> > From Peter Hutterer  earlier:
> > ```
> >  but you don't necessarily have
> > access to how Xwayland is started (mutter certainly is hard-coded).
> > ```
> 
> Correct, the Wayland compositor is responsible for starting up XWayland
> and that's not always configurable. I've filed bugs for mutter, kwin and
> wlroots so the developers are aware and that should cover the majority
> of Wayland use-cases once fixed.

just a minor follow-up: mutter has that feature merged now for GNOME 43
[1] so a once-off gsettings call should do the trick there:

$ gsettings set org.gnome.mutter.wayland xwayland-allow-byte-swapped-clients 
true

Cheers,
  Peter


[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote:
> On Thu, 5 Jan 2023 at 08:20, David Cantrell  wrote:
> 
> > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote:
> > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote:
> > > [...]
> > > > > So I guess this means no remoting into ppc64 or s390x machines from
> > > > > x86_64 or ppc64le machines without a configuration tweak?
> > > >
> > > > We don't have ppc64 builds anymore and I don't know the last release
> > we had
> > > > that was ppc64, but it was a long time ago now.  All current POWER
> > systems are
> > > > ppc64le.
> > > >
> > > > And everything else we have as primary or alternative architectures is
> > little
> > > > endian, except s390x.  I do view this as a risk for s390x because of
> > all the
> > > > architectures we build for, this one is the most difficult to use
> > graphically.
> > > > Exporting your display is still the convenient method for this
> > platform.
> > > >
> > > > Given that this change proposal affects default behavior, I don't see a
> > > > problem with it.  s390x users can drop the configuration change in
> > xorg.conf.d
> > > > to regain the functionality.  If that can be conditionally enabled for
> > s390x
> > > > at package build time, that might make things easier (but wouldn't you
> > need to
> > > > make the change on both the s390x host and your non-s390x
> > workstation?).
> > >
> > > The X protocol works that the first byte of the connection request is a
> > > either 'l' or 'B', telling the server that the client is little or Big
> > > endian. The client has no information on the server's endianess.
> > >
> > > This means the configuration needs to be done wherever your X server
> > > runs, so the (little-endian) thing you're sitting in front of. Which is
> > > also why compile-time defaults are difficult, at compile time we cannot
> > > know that eventually you may want to connect from an s390x.
> >
> > Reasonable.  The runtime configuration change I can make locally to allow
> > me
> > to run X programs on an s390x and display them locally is sufficient for
> > me.
> >
> 
> Wasn't there a concern that you can do this if you are running a desktop
> with X, but if you are using Xwayland it isn't easy (or maybe possible) as
> the configuration to do that was either hardcoded or not fully documented
> on how to do that?
> 
> From Peter Hutterer  earlier:
> ```
>  but you don't necessarily have
> access to how Xwayland is started (mutter certainly is hard-coded).
> ```

Correct, the Wayland compositor is responsible for starting up XWayland
and that's not always configurable. I've filed bugs for mutter, kwin and
wlroots so the developers are aware and that should cover the majority
of Wayland use-cases once fixed.

Cheers,
   Peter



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote:
[...]
> > So I guess this means no remoting into ppc64 or s390x machines from
> > x86_64 or ppc64le machines without a configuration tweak?
> 
> We don't have ppc64 builds anymore and I don't know the last release we had
> that was ppc64, but it was a long time ago now.  All current POWER systems are
> ppc64le.
> 
> And everything else we have as primary or alternative architectures is little
> endian, except s390x.  I do view this as a risk for s390x because of all the
> architectures we build for, this one is the most difficult to use graphically.
> Exporting your display is still the convenient method for this platform.
> 
> Given that this change proposal affects default behavior, I don't see a
> problem with it.  s390x users can drop the configuration change in xorg.conf.d
> to regain the functionality.  If that can be conditionally enabled for s390x
> at package build time, that might make things easier (but wouldn't you need to
> make the change on both the s390x host and your non-s390x workstation?).

The X protocol works that the first byte of the connection request is a
either 'l' or 'B', telling the server that the client is little or Big
endian. The client has no information on the server's endianess.

This means the configuration needs to be done wherever your X server
runs, so the (little-endian) thing you're sitting in front of. Which is
also why compile-time defaults are difficult, at compile time we cannot
know that eventually you may want to connect from an s390x.

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Thu, Dec 22, 2022 at 11:30:33AM +0100, Niklas Schnelle wrote:
> Hi All,
> 
> This might not be as niche as you might think. I'm one of the
> Linux kernel maintainers for s390. Many of us do the vast majority of
> their development work natively on s390 systems via SSH from Fedora
> laptops. After all mainframes are pretty damn fast at compiling with
> plenty of memory and dog fooding is part of quality control. And I'm
> sure it's not just the teams working on the Linux kernel but also
> plenty of other people working with s390 Linux machines. These s390
> machines mostly only host X servers via VNC and usually just for the
> installation but they do that too. There is also a hand full of X
> clients I run on s390 which are essential for my and many of my
> colleagues daily workflows. The most important one is defintely
> xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local
> system. Some people also use x3270 via SSH X forwarding from jumphosts,
> others use XEmacs. I also know essential internal tools that are run on
> s390 hosts via X forwarding. Sure people using X forwarding are capable
> of changing configuration defaults but if at all possible I would
> suggest to rethink this, as it will create significant hassle for
> anyone using their Fedora systems to SSH + X forward to s390 Linux
> hosts and it definitely sees more use and thus testing than the
> proposal makes it sound.

One main question here is: how many of you use Wayland already? Right
now the biggest issue with this change is IMO the inability to configure
this for Wayland compositors until they add the respective option. Xorg
is easy to fix with an xorg.conf snippet, but you don't necessarily have
access to how Xwayland is started (mutter certainly is hard-coded).

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Thu, Dec 29, 2022 at 11:27:01AM -0800, John Reiser wrote:
> On 12/21/22 13:49, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
> 
> > X server implementations (e.g. Xorg and Xwayland) allow clients with
> > an endianess different to that of the server to connect. Protocol
> > messages to and from these clients are byte-swapped by the X server.
> > However, the code in the X server that does this is virtually
> > untested, providing a large attack surface for malicious clients.
> 
> There is a technological solution which eradicates the byte-swapped
> attack surface.  All existing byte-swapping bugs (known and unknown)
> are fixed, and all future byte-swapping bugs are prevented.
> 
> In C++, re-code each 'struct' by using a typedef for each
> member that can suffer byte-swapping.  Create a template for
> each struct containing such members, where the typedefs for
> members are template parameters for the templated struct.
> Create a template for each function which uses such structs,
> again with the typedefs as template parameters (possibly subsumed
> inside other templated objects.)
> When the X server accepts a connection from a client of different
> endian-ness, then automatic template instantiation and matching
> by the C++ compiler will invoke the correct top-level function(s),
> which will invoke the correct lower-level functions.
> 
> An example is  https://github.com/upx/upx/blob/devel/src/p_mach.h
> and p_mach.cpp, which handles both width (32 vs 64) and endian-ness
> for processing any Mach-O executable by the UPX program compressor
> running on any machine (same or different width and endian-ness).
> 
> A years-earlier "by-hand" example of related coding in plain-C is
> scripts/recordmcount.c  in the source code for Linux kernel.

Interesting approach, but the X server is written in C, introducing C++
is not going to happen in a project that's in maintenance mode. Even if 
anyone could find the time to do it and figure out how to test all the
changes afterwards.

It's not all structs either (and there's *a lot* of thos, probably well
over 1000), sometimes it's something like this:

  struct XSomething *foo;
  uint32_t len = (uint32_t*)(foo + 1);

and other similar approaches. Which means not every 16/32 bit number is
part of a struct. 

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Wed, Dec 28, 2022 at 10:16:45PM -0500, Neal Gompa wrote:
> On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer
>  wrote:
> >
> > On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote:
> > > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle  
> > > wrote:
> > > >
> > > > Hi All,
> > > >
> > > > This might not be as niche as you might think. I'm one of the
> > > > Linux kernel maintainers for s390. Many of us do the vast majority of
> > > > their development work natively on s390 systems via SSH from Fedora
> > > > laptops. After all mainframes are pretty damn fast at compiling with
> > > > plenty of memory and dog fooding is part of quality control. And I'm
> > > > sure it's not just the teams working on the Linux kernel but also
> > > > plenty of other people working with s390 Linux machines. These s390
> > > > machines mostly only host X servers via VNC and usually just for the
> > > > installation but they do that too. There is also a hand full of X
> > > > clients I run on s390 which are essential for my and many of my
> > > > colleagues daily workflows. The most important one is defintely
> > > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local
> > > > system. Some people also use x3270 via SSH X forwarding from jumphosts,
> > > > others use XEmacs. I also know essential internal tools that are run on
> > > > s390 hosts via X forwarding. Sure people using X forwarding are capable
> > > > of changing configuration defaults but if at all possible I would
> > > > suggest to rethink this, as it will create significant hassle for
> > > > anyone using their Fedora systems to SSH + X forward to s390 Linux
> > > > hosts and it definitely sees more use and thus testing than the
> > > > proposal makes it sound.
> > > >
> > >
> > > How bad would it be to force little-endian for the X protocol
> > > regardless of architecture?
> >
> > simply said - not realistic. It's a lot of effort, with zero visible
> > benefit beyond the *potential* that we're slightly safer now. Which you
> > won't know until you tested it all.
> >
> > The code works, at least for the bits that are executed. Swapped clients
> > run on different hosts by definition so there are probably whole
> > extensions that are never used at all and likely completely untested.
> > And it's not a matter of "working" but "safe against a malicious client
> > sending bad messages". That's a completely different ballpark.
> > e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one
> > ever noticed the issue - because it works as long as the client is nice.
> >
> > Forcing the server to little endian only means you'd need to do the
> > swapping client-side. There is nothing in place right now to do this and
> > while it's probably possible to automate this somewhat with xcb, you're
> > still looking at a huge project. And once it all works, you need to
> > ensure it works against malicious input data. You could *possibly* MITM
> > the whole protocol-swapping into a separate process but, well, goto 10
> > :)
> >
> 
> Please tell me the Wayland protocol doesn't do this? 

the wayland protocol doesn't to this :)

Wayland integers must be encoded in the host's (read: compositor) byte
order. Somewhat of an exception are the wl_shm image formats which
are (apparently) always in little-endian [1].

Cheers,
 Peter

[1] https://wayland.freedesktop.org/docs/html/apa.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote:
> On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle  
> wrote:
> >
> > Hi All,
> >
> > This might not be as niche as you might think. I'm one of the
> > Linux kernel maintainers for s390. Many of us do the vast majority of
> > their development work natively on s390 systems via SSH from Fedora
> > laptops. After all mainframes are pretty damn fast at compiling with
> > plenty of memory and dog fooding is part of quality control. And I'm
> > sure it's not just the teams working on the Linux kernel but also
> > plenty of other people working with s390 Linux machines. These s390
> > machines mostly only host X servers via VNC and usually just for the
> > installation but they do that too. There is also a hand full of X
> > clients I run on s390 which are essential for my and many of my
> > colleagues daily workflows. The most important one is defintely
> > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local
> > system. Some people also use x3270 via SSH X forwarding from jumphosts,
> > others use XEmacs. I also know essential internal tools that are run on
> > s390 hosts via X forwarding. Sure people using X forwarding are capable
> > of changing configuration defaults but if at all possible I would
> > suggest to rethink this, as it will create significant hassle for
> > anyone using their Fedora systems to SSH + X forward to s390 Linux
> > hosts and it definitely sees more use and thus testing than the
> > proposal makes it sound.
> >
> 
> How bad would it be to force little-endian for the X protocol
> regardless of architecture?

simply said - not realistic. It's a lot of effort, with zero visible
benefit beyond the *potential* that we're slightly safer now. Which you
won't know until you tested it all.

The code works, at least for the bits that are executed. Swapped clients
run on different hosts by definition so there are probably whole
extensions that are never used at all and likely completely untested.
And it's not a matter of "working" but "safe against a malicious client
sending bad messages". That's a completely different ballpark.
e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one
ever noticed the issue - because it works as long as the client is nice.

Forcing the server to little endian only means you'd need to do the
swapping client-side. There is nothing in place right now to do this and
while it's probably possible to automate this somewhat with xcb, you're
still looking at a huge project. And once it all works, you need to
ensure it works against malicious input data. You could *possibly* MITM
the whole protocol-swapping into a separate process but, well, goto 10
:)

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

[Peter Hutterer]

On Thu, Dec 22, 2022 at 09:17:28PM +0100, Björn Persson wrote:
> Vít Ondruch wrote:
> > Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a):
> > > When the connection fails, the Xserver returns a reason in plain text.
> > > In that case, the reason for the connection being rejected would be
> > > „Swapped clients prohibited“.  
> > 
> > Appreciate that there is at least some explanation, but if I saw this 
> > error, I would not be much smarter what is going on and how should I 
> > proceed 
> 
> Yes, that's a really bad error message. My reaction would be "What
> nonsense is that? I haven't swapped any clients." If it had at least
> said "byte-swapped" it would probably have gotten me searching in the
> right direction, but if the X server wants to be helpful it should say
> "big/little-endian mismatch; the option AllowSwappedClients is off".

Thanks, I've changed the error message to say `byte-swapped`, it hasn't
been merged upstream yet after all. This particular message is handled
in the DDX-independent bits though (shared code for Xorg, Xwayland,
etc.), the option AllowSwappedClients only exists for Xorg since the
other X server don't have an xorg.conf.

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libwacom soname bump

[Peter Hutterer]

Hi all,

libwacom had a soname bump for the upcoming release. I've already rebuilt
- libinput
- cinnamon, cinnamon-control-center and cinnamon-settings-daemon
- mutter, gnome-control-center, gnome-settings-daemon
- kcm_wacomtablet (FTBFS though, #2031611)

That should be it, if you have a package not in the above list that uses
libwacom please let me know though, I'd be interested to hear about it.

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Excessive Messages In Journal From pipewire

[Peter Hutterer]

On Tue, Aug 03, 2021 at 05:33:28PM -0400, Garry T. Williams wrote:
> This seems obnoxious:
> 
> Aug 03 17:24:24 pipewire[3007]: 1 events suppressed
> Aug 03 17:24:24 pipewire[3007]: (speech-dispatcher-espeak-ng-54) client 
> too slow! rate:256/48000 pos:968996864 status:triggered
> Aug 03 17:24:24 pipewire[3007]: (speech-dispatcher-dummy-60) client too 
> slow! rate:256/48000 pos:968996864 status:triggered
> Aug 03 17:24:24 pipewire-pulse[3008]: (speech-dispatcher-dummy-0) client 
> missed 1 wakeups
> Aug 03 17:24:29 pipewire[3007]: 1 events suppressed
> Aug 03 17:24:29 pipewire[3007]: 
> (bluez_output.00_0D_44_DE_D4_EA.a2dp-sink-48) client too slow! rate:256/48000 
> pos:969237504 status:triggered
> Aug 03 17:24:29 pipewire[3007]: 
> (bluez_output.00_0D_44_DE_D4_EA.a2dp-sink-48) client too slow! rate:256/48000 
> pos:969237504 status:triggered
> Aug 03 17:24:29 pipewire[3007]: 
> (bluez_output.00_0D_44_DE_D4_EA.a2dp-sink-48) client missed 2 wakeups
> Aug 03 17:24:29 pipewire-pulse[3008]: (speech-dispatcher-dummy-0) client 
> missed 1 wakeups
> Aug 03 17:24:29 pipewire-media-session[3014]: 
> (bluez_output.00_0D_44_DE_D4_EA.a2dp-sink-19) client missed 1 wakeups
> 
> $ journalctl -b|grep -c 'client too slow!'
> 7798
> $ rpm -qa|grep pipewire
> pipewire-libs-0.3.32-1.fc34.x86_64
> pipewire-0.3.32-1.fc34.x86_64
> pipewire-alsa-0.3.32-1.fc34.x86_64
> pipewire-pulseaudio-0.3.32-1.fc34.x86_64
> pipewire-jack-audio-connection-kit-0.3.32-1.fc34.x86_64
> $ uptime
>  17:31:17 up  5:45,  4 users,  load average: 0.62, 0.77, 0.85
> $
> 
> Anyone know how to turn this off?

Nothing specific to turn this off without lowering pipewire's general debug
levels. Upstream bug is here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1410

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Switch to WirePlumber as the PipeWire session manage (late Self-Contained Change proposal)

[Peter Hutterer]

On Tue, Jul 20, 2021 at 05:44:42PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 20, 2021 at 07:21:07PM +0200, gerard.bi...@gmail.com wrote:
> > Hi,
> >  a happy user of F35 here.
> > 
> > With PipeWire since two weeks. Which stopped working with the last update.
> > 
> > Finding this page [1], I installed WirePlumber. It
> > removed pipewire-media-session.
> > 
> > I didn't have to do anything more than dnf install xxx. I looked for
> > potential systemctl commands, but I found nothing needed.
> 
> Oh, right. wireplumber.rpm conflicts with pipewire-media-session.rpm,
> so what I wrote it unnecessary.

ftr, you can change between the two packages with
  dnf swap wireplumber pipewire-media-session
  dnf swap pipewire-media-session wireplumber

Everythingthing else should work magically provided 
fedora-release-35 packages are up to date.

Cheers,
  Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd unit auto-enabling question

[Peter Hutterer]

On Fri, Jun 18, 2021 at 09:02:08AM -0500, Michael Catanzaro wrote:
> On Fri, Jun 18 2021 at 08:02:05 AM +1000, Peter Hutterer
>  wrote:
> > Right now pipewire gets around this by hardcoding pipewire-media-session
> > and
> > starting it directly (instead of the systemd service) but that makes it
> > hard
> > to replace.
> > 
> > Anyway, sounds like I'd need to get the FESCo approval for both packages
> > then?
> 
> Yes, you need FESCo approval to modify 90-default-user.preset. But also, I
> see I don't have pipewire-media-session installed at all on F34, so you'll
> also need Workstation WG approval to add a new package if you want one of
> these to be installed by default. (I don't know what they do, or why they
> were not included in the F34 change.)

Right now, pipewire-media-session is part of the pipewire package itself and
started by the pipewire daemon. So you do have it, just not as individual
package :) Check your ps output, it's running.

The goal is to make it replaceable which would require a separate package,
but yes, that will also require some other hoops to jump through, the
systemd part is merely the first one of those.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: systemd unit auto-enabling question

[Peter Hutterer]

On Thu, Jun 17, 2021 at 07:48:24AM -0500, Michael Catanzaro wrote:
> On Thu, Jun 17 2021 at 11:52:44 AM +1000, Peter Hutterer
>  wrote:
> > What I need is manager.service being auto-enabled at install time. How
> > do I
> > get this done?
> 
> Hi, you're missing a systemd preset. You generally need FESCo approval to
> add a preset. See:
> 
> * https://src.fedoraproject.org/rpms/fedora-release/tree/rawhide,
> specifically 90-default-user.preset
> * https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/
> 
> That said, we already have user session presets for pipewire in
> 90-default-user.preset:
> 
> enable pipewire.socket
> enable pipewire-pulse.socket
> 
> This allows Pipewire to be enabled by default, but via socket activation
> only. The lack of a preset for pipewire.service itself seems to be
> intentional.

Thanks for the info. The preset for pipewire.socket affects only the daemon
itself, not the manager process (pipewire-media-session or wireplumber,
depending on which one of the two is installed).

What this means is that pipewire starts up fine after installing, but
neither management daemon starts automatically after install, it needs the
manual systemctl enable.

Right now pipewire gets around this by hardcoding pipewire-media-session and
starting it directly (instead of the systemd service) but that makes it hard
to replace.

Anyway, sounds like I'd need to get the FESCo approval for both packages
then?

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

systemd unit auto-enabling question

[Peter Hutterer]

I'm running around in circles here not getting anywhere, so maybe someone
on this list has the answer :)

I have three packages [1], lets call them
- server
- manager (Conflicts: alternative-manager)
- alternative-manager (Conflicts: manager)

The server on its own is relatively dumb, it needs a manager to function
(there are niche cases where only the server should exist). The server is
socket-activated and server.socket is enabled in the systemd presets so that
will start as part of the user session.

In the manager's .service file I have
[Unit]
BindsTo=server.service

[Install]
WantedBy=server.service

This ties it to the server and starts/stops it automatically.
But: this only happens once I *manually* run systemctl enable manager.service.

What I need is manager.service being auto-enabled at install time. How do I
get this done?

I cannot rely on it from server.service either because alternative-manager
may be installed with a different .service file.

Any ideas?

Cheers,
   Peter

[1] the actual packages are pipewire, pipewire-media-session and wireplumber
but doesn't matter for the approach here
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning luit

[Peter Hutterer]

I've orphaned luit. The only user of it was xterm and it recently dropped
support for luit so there are no users left. Whether there are *any* users
left is unclear too :)

The luit package we shipped is still the freedesktop.org one which has been
unmaintained for about a decade now. Upstream now points to
Thomas Dickey's fork at http://invisible-island.net/luit/ so if anyone
wants to take this, I advise switching to that version as part of the first
steps.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning xfontsel

[Peter Hutterer]

I've orphaned xfontsel, one of the many possibly-older-than-thou X
utilities. From the man page: 

  xfontsel - point and click selection of X11 font names

So it does support both point *and* click. Futuristic stuff indeed ;)

Package is here if you want to take it:
https://src.fedoraproject.org/rpms/xfontsel

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring a set of old X utilities

[Peter Hutterer]

On Fri, Apr 23, 2021 at 06:25:21PM +0900, Stephen J. Turnbull wrote:
> Peter Hutterer writes:
> 
>  > Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
>  > retire a set of old X utilities that I think don't need to be in Fedora:
>  > 
>  > oclock
>  > xbiff
>  > xload
>  > xman
>  > xrefresh
>  > xlogo
>  > xpr
>  > xfd
>  > viewres
>  > listres
>  > xconsole
> 
> Wow.  Can't argue that any of them should be in Fedora (although xlogo
> is in the X11 menu on my Mac! ;-), but seeing those retired is like
> going back to my hometown and discovering that my elementary school
> was replaced by a personal finance consultancy and barbershop.  :-)

don't worry, xeyes will stay around for the forseeable future, so just
direct all your sentinmental memories to that :)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Orphaning appres, editres, listres, viewres

[Peter Hutterer]

appres is used by xscreensaver, editres *may* be used by grace. I've
contacted both maintainers directly to notify them.

listres and viewres appear to be unused by any other packages.

All package average 1-2 commits per year upstream and almost all of these
are housekeeping. The codebase is 20+ years old, so do bring a pith
helmet and a torch.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring a set of old X utilities

[Peter Hutterer]

On Thu, Apr 22, 2021 at 11:14:44AM +0200, Miro Hrončok wrote:
> On 22. 04. 21 4:03, Peter Hutterer wrote:
> > Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
> > retire a set of old X utilities that I think don't need to be in Fedora:
> > 
> > oclock
> > xbiff
> > xload
> > xman
> > xrefresh
> > xlogo
> > xpr
> > xfd
> > viewres
> > listres
> > xconsole
> > 
> > This is a very conservative list of packages, there are likely more
> > that should be on this list but for now, this is a start.
> > 
> > If you are using any of the above, please let me know and I'll hand the
> > package over to you - it's either retirement or you take over the package
> > maintainership.
> 
> Please, orphan the packages instead. They will be retired in 6 weeks if
> nobody takes them.

good idea, thanks. I'll do that instead.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring a set of old X utilities

[Peter Hutterer]

On Thu, Apr 22, 2021 at 12:37:40AM -0400, DJ Delorie wrote:
> Peter Hutterer  writes:
> > xfd
> 
> I use this a lot; what is the modern replacement for it?

I was about to say gnome-font-viewer but that doesn't seem to list the old X
fonts (or requires conversion or something). So, tbh, I'm not sure there is
one.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Retiring a set of old X utilities

[Peter Hutterer]

Now that the XorgUtilityDeaggregation [1] is complete, I'm planning to
retire a set of old X utilities that I think don't need to be in Fedora:

oclock
xbiff
xload
xman
xrefresh
xlogo
xpr
xfd
viewres
listres
xconsole

This is a very conservative list of packages, there are likely more
that should be on this list but for now, this is a start.

If you are using any of the above, please let me know and I'll hand the
package over to you - it's either retirement or you take over the package
maintainership.

Cheers,
   Peter

[1] https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

License change: libevdev -> MIT

[Peter Hutterer]

Thanks to a copy/paste error many years ago, libevdev's COPYING file
contained the HPND sell variant [1], not the intended MIT license. This has
been fixed upstream with the 1.11.0 release which is currently hitting the
Fedora repos.

libevdev was always meant to be MIT, from the developer's perspective this
isn't a license change as such, it's more getting the paperwork in order.
From a legal perspective... IANAL.

Cheers,
   Peter

[1] https://spdx.org/licenses/HPND-sell-variant.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: GitRepos-master-to-main (Self-Contained Change)

[Peter Hutterer]

On Fri, Dec 04, 2020 at 04:24:26PM -0500, DJ Delorie wrote:
> Daniel P. Berrangé  writes:
> > Perhaps this is heresy, but we could stop calling our main development
> > stream "rawhide", and instead call it "main", then it will be trivially
> > aligned with the "main" git branch name :-)
> 
> But fedoras aren't made of sheets of main, they're made from sheets of
> rawhide...

I'd venture there's a significant percentage of users and developers that
aren't aware that a Fedora is hat. Not everyone is a native English speaker.

I certainly knew about Fedora-the-distro for years before some off-hand
comment made me realise that it's a type of hat. And the only reference to
rawhide I've ever known before working on Fedora was the Blues Brothers
song.

On a global scale, a lot of these puns are meaningless since they're too
tied to the local culture (well, almost always the US one).

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Retiring xkbevd, xkbprint, xkbutils

[Peter Hutterer]

As part of the XorgUtilityDeaggregation [1], I'm planning to retire these
three. They're currently part of xorg-x11-xkb-utils-extras, a subpackage of
xorg-x11-xkb-utils (which provides setxkbmap and xkbcomp).

setxkbmap and xkbcomp will be split into their own packages and both will
Obsolete: xorg-x11-xkb-utils.

tigervnc [2] and x2goserver [3] still need to have their Requires fixed, but
otherwise we're good to go here, I think.

For the other three packages, I don't think it's worth the effort of
creating new packages for them:
- xkbprint: one upstream bug report in the last 7 years
- xkbevd: no upstream bug reports
- xkbwatch: one bug report two years ago but with lack of reviewers and
  motivation of the reporter it fizzled out

Upstream development is zero except for the usual janitorial patches that
apply to all xorg packages (like the gitlab switch).

So, right now my plan is to simply retire the xorg-x11-xkb-utils package
once xkbcomp/setxkbmap are avilable and let these three packages descend
into oblivion. They can be resurrected by a willing maintainer as separate
packages if need be.

If that doesn't work for some reason, please speak up now.

Cheers,
   Peter

[1] https://fedoraproject.org/wiki/Changes/XorgUtilityDeaggregation
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894787
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1894794
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Hutterer]

On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote:
> On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote:
> > > From this thread you can find at least two people (me and Ben
> > > Rosser)
> > > who definitely didn't keep using vi (my very next questions were
> > > "what's an easier editor to use?" and "how do I change the default
> > > editor to something else?"), and are still sufficiently frazzled by
> > > the
> > > experience that we still refuse to. :P
> 
> > Right, and I acutally think thats great.  You had a problem, you
> > asked the
> > questions you needed answers to, and solved your problem.  I
> > personally think
> > the process of identifying whats bothering you, figuring out a
> > solution (by
> > asking questions, getting answers and experimenting), and then
> > implementing your
> > fix is actually a pretty good user experience in and of itself
> > (though that may
> > just be me). :)
> 
> That is not how it felt at the time :P
> 
> It's really the point about Unexpected Forcible Learning. If I sit down
> at my computer and think "right, I'm going to learn to do X", that's
> one thing. I am mentally prepared to spend some time stumbling around
> working out how to do X.
> 
> The problem with this experience is that's not how it happens. You
> don't sit down and thinking "today I'm going to learn how to use vi" or
> "today I'm going to learn about console text editors and the $EDITOR
> variable". You were intending to do something else, and you were
> suddenly sandbagged by this fracking weird thing you have no idea what
> it is that got in the way of the something else you were trying to do.
> 
> Yes, eventually you learn something, but it's not a "pretty good user
> experience", it is a frustrating and annoying one.

/me puts a tinfoil hat on

what if... what IF ... this whole "vi by default" is a huge conspiracy by
the emacs people to make new users hate vi from the earliest stages, thus
providing a welcoming environment for them to swoop in and save them with
promises of strange shortcuts! I knew it all along!

/me completely wraps himself in tinfoil [1]


[1] well, aluminium foil because it's too hard to get decent tinfoil these
days, not like back in my days when it was snowing uphill both ways
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Peter Hutterer]

On Thu, Jun 25, 2020 at 11:38:13PM +0200, Jan Kratochvil wrote:
> On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> > I'm not sure why you think end-users can't use a free OS.
> 
> First steps of end-users is to install Chrome, Spotify and VirtualBox.
> So there is left no advantage of a Free OS.
> 
> 
> > I've run with SELinux enabled for years, rarely if ever causes problems
> > for typical stuff.
> 
> Sooner or later something does not work. I do not want to open this can of
> worms whether SELinux yes or not, it may be a good idea but IMNSHO it is not
> for a development machine.
> 
> 
> > I have no idea why you'd remove a useful tool like bash-completion.  It
> > has lots of things useful for developers.
> 
> I agree the idea of bash-completion is nice. But it is so severly incomplete
> it is more a burden than help. Unfortunately I no longer remember all the bugs
> I faced before I started removing it years ago but a simple one is:
> 
> $ wget -O somepackage.rpm https://...
> $ dnf install som
> 
> $ dnf install sombok-

disclaimer: I'm using zsh, not bash but it has the same issue. But IMO you
can't really blame it - how is the completion to know that you want to
install an RPM in the current directory? The correct way would be
dnf install ./some
and that completes immediately (on zsh). Does that work on bash?

Cheers,
   Peter

 
> > Unless you are doing kernel development, why do you care what the kernel
> > messages say?  On my systems, they go by too fast to read anyway.
> 
> When it locks up (during updating firmware on my Athlon machine) I see just
> a black screen. When I reboot without rhgb/quiet the problem is not
> reproducible as it happens only rarely. There are many reasons why kernels
> sometimes fail to boot, why to give up on troubleshooting?
> 
> 
> Jan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: What to do when packagers "forget" bodhi updates for branched (f32)?

[Peter Hutterer]

On Tue, Mar 17, 2020 at 11:45:10AM +0100, Fabio Valentini wrote:
> On Tue, Mar 17, 2020 at 12:46 AM Peter Hutterer
>  wrote:
> >
> > On Mon, Mar 16, 2020 at 09:30:51PM +0100, Fabio Valentini wrote:
> > > Hi everybody,
> > >
> > > It's that time of the semi-year again, and I again found multiple
> > > instances of packages that have updates for rawhide and f31/f30, but
> > > no bodhi update for fedora 32.
> > >
> > > In most cases, the updated package was built on fedora 32 (a koji
> > > build was successful), but no bodhi update was created. In some cases,
> > > f32 was "forgotten" entirely.
> > >
> > > So, assuming the best, those packagers simply forgot that bodhi
> > > updates are necessary for branched releases after the beta freeze.
> > >
> > > What is the best couse of action for such forgotten updates? Some are
> > > bugfixes, others are new versions, and some could be security fixes,
> > > that are then missing from f32 entirely.
> 
> (snip)
> 
> > I pushed a few updates after branching where I did try to submit updates and
> > bodhi rejected them (too early) and then I simply missed the point where
> > they became necessary.
> >
> > so for me - an email to fedora-{devel|announce} with "bodhi updates for f32
> > are required now" would be good. the more obvious the subject line the
> > better. if that email was indeed sent and I missed it - oops and my
> > apologies :)
> 
> There was an announcement sent to test@, test-announce@, and devel-announce@:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/UJRPBSP2BP6MM42NW5NM5WTMQY7WCT4V/
> 
> The subject "Fedora 32 Beta Freeze" isn't so clear though.
> That "Beta Freeze" means that creating updates in bodhi starts being
> necessary is only "hidden" in the first or second paragraph.

yup, checked and I did get this. I probably read the subject line and was
generally aware of the freeze but I don't think I read the email itself. So
yeah, having an email with the subject line containing important
instructions like the above would still help for some people, specifically
me :)

Cheers,
   Peter


> 
> > Failing all that, screaming at the maintainer in the most appreciative and
> > respectful way is always a good way to get things fixed too :)
> 
> I try to not scream at anybody, particularly not at those who do show
> up and do the work :)
> 
> > > I *could* file bodhi updates for everything that's missing from f32,
> > > but I do not want to interfere with others' work here.
> > >
> > > Filing bodhi comments on the updates that break the upgrade path
> > > (f31/f30, in this case) is not productive either, since those comments
> > > are often ignored in my experience.
> > >
> > > A few examples that popped up on my systems (I'm sure there are more):
> > >
> > > 1) dnsmasq-2.80-12.fc31 is going to f31 stable:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c
> > > The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji,
> > > but then an internal koji error broke it. It wasn't resubmitted, and
> > > there's no bodhi update for it:
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221
> > >
> > > 2) libinput-1.15.3-2.fc31 is going to f31 stable:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e
> > > The corresponding f32 build in koji was successful, but no bodhi
> > > update is associated with it:
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404
> >
> > fixed now, apologies for the mess.
> >
> > Cheers,
> >Peter
> 
> Thank you!
> 
> Fabio
> 
> > >
> > > 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161
> > > The update to 3.1.3 has been built for f33 and f31, but not for f32.
> > > The 3.1.3 changes aren't even merged from master into the f32 branch
> > > in dist-git.
> > >
> > > Any suggestions what we could do to make sure f32 updates aren't
> > > forgotten after the beta freeze?
> > >
> > > Fabio
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > >

Re: What to do when packagers "forget" bodhi updates for branched (f32)?

[Peter Hutterer]

On Mon, Mar 16, 2020 at 09:30:51PM +0100, Fabio Valentini wrote:
> Hi everybody,
> 
> It's that time of the semi-year again, and I again found multiple
> instances of packages that have updates for rawhide and f31/f30, but
> no bodhi update for fedora 32.
> 
> In most cases, the updated package was built on fedora 32 (a koji
> build was successful), but no bodhi update was created. In some cases,
> f32 was "forgotten" entirely.
> 
> So, assuming the best, those packagers simply forgot that bodhi
> updates are necessary for branched releases after the beta freeze.
> 
> What is the best couse of action for such forgotten updates? Some are
> bugfixes, others are new versions, and some could be security fixes,
> that are then missing from f32 entirely.

I pushed a few updates after branching where I did try to submit updates and
bodhi rejected them (too early) and then I simply missed the point where
they became necessary.

so for me - an email to fedora-{devel|announce} with "bodhi updates for f32
are required now" would be good. the more obvious the subject line the
better. if that email was indeed sent and I missed it - oops and my
apologies :)

Failing all that, screaming at the maintainer in the most appreciative and
respectful way is always a good way to get things fixed too :)
 
> I *could* file bodhi updates for everything that's missing from f32,
> but I do not want to interfere with others' work here.
> 
> Filing bodhi comments on the updates that break the upgrade path
> (f31/f30, in this case) is not productive either, since those comments
> are often ignored in my experience.
> 
> A few examples that popped up on my systems (I'm sure there are more):
> 
> 1) dnsmasq-2.80-12.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-aab29ac03c
> The corresponding f32 build (dnsmasq-2.80-13.fc32) succeeded in koji,
> but then an internal koji error broke it. It wasn't resubmitted, and
> there's no bodhi update for it:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42386221
> 
> 2) libinput-1.15.3-2.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-d66ed9f32e
> The corresponding f32 build in koji was successful, but no bodhi
> update is associated with it:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1475404

fixed now, apologies for the mess.

Cheers,
   Peter

> 
> 3) python-matplotlib-3.1.3-1.fc31 is going to f31 stable:
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-188dd2b161
> The update to 3.1.3 has been built for f33 and f31, but not for f32.
> The 3.1.3 changes aren't even merged from master into the f32 branch
> in dist-git.
> 
> Any suggestions what we could do to make sure f32 updates aren't
> forgotten after the beta freeze?
> 
> Fabio
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

[Peter Hutterer]

On Sat, Jan 04, 2020 at 12:15:20PM -0600, Michael Catanzaro wrote:
> Let's keep this desktop-focused, since the proposal does not affect Server
> edition.
> 
> On Sat, Jan 4, 2020 at 12:48 pm, drago01  wrote:
> > As for the desktop case the running web browers in a cgroup to keep them
> > in check would solve most real world problems - other common desktop
> > apps don't use enough memory to cause such issues (unless your system is
> > really memory constrained but then the "buy more memory" solution is the
> > better fix).
> 
> The last time I saw my desktop hang due to a web browser using too much
> memory was 2015.

just FTR, this happens relatively frequently for me. Some websites seem to
cause Firefox to swap itself into nirvana. Sometimes within a short time
but sometimes it takes longer. I've come back from a lunch break a few times
to a desktop swapping itself to death.

Not yet fully identified but it does happen.

Cheers,
   Peter

> 
> The freezes I've encountered in the past five years were all related to
> software development:
> 
> * When compiling large software projects, it's possible to run out of RAM
> either when building lots of files in parallel, or when linking
> * GNOME Builder runs ctags, and ctags likes to use dozens of GB of RAM to
> index large software projects. I think it sometimes gets into a loop where
> it just allocates more and more RAM until the desktop dies
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disappearing mouse pointer

[Peter Hutterer]

On Wed, Aug 07, 2019 at 09:55:02AM -0600, Chris Murphy wrote:
> On Wed, Aug 7, 2019 at 9:03 AM Jerry James  wrote:
> >
> > I use the default GNOME desktop, using Wayland with Intel graphics.  I
> > have a web browser, a terminal, and an editor running on desktop 1.
> > On desktop 2 (i.e., where Ctrl-Alt-Down takes you) I have virt-manager
> > running, with open windows for whichever VMs are currently in use.
> >
> > Yesterday, I updated my Fedora 30 machine.  See the list of updated
> > packages below.  After rebooting into the new kernel, I interacted
> > with a CentOS 7 VM for maybe 10 minutes.  When I moved the mouse
> > pointer out of the VM window on desktop 2, the pointer vanished.  That
> > is, the mouse pointer is now invisible on desktop 2, except when it is
> > inside the VM window.  If I switch back to desktop 1, the mouse
> > pointer is visible, unless I move it onto the menu bar at the top of
> > the screen, where it also vanishes.
> >
> > Logging out and then back in restored the mouse pointer, but after
> > working with the VM for just a few minutes, the mouse pointer
> > disappeared again, exactly as before.  Opening system settings brought
> > the mouse pointer back, for some reason.
> 
> Weirdly I'm not seeing this on Fedora 30, I'm only seeing it on
> Rawhide, and I haven't figured out a pattern because it doesn't always
> happen.
> 
> Also I'm only using Rawhide VM's in virt-manager, so I'm not certain
> the guest matters but that's speculative. Definitely it's related to
> virt-manager and intel graphics because I'm not using anything other
> than those two.
> 
> My Fedora 30 laptop has
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Skylake
> GT2 [HD Graphics 520] [8086:1916] (rev 07) (prog-if 00 [VGA
> controller])
> 
> My Fedora 31 laptop (with this transient issue) has
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd
> Generation Core Processor Family Integrated Graphics Controller
> [8086:0126] (rev 09) (prog-if 00 [VGA controller])
> 
> So it might be a controller specific bug, possibly kernel regression.
> But I'm not sure what components are responsible for the drawing of
> the pointer, and how it's negotiated when it transitions a
> virt-manager guest window, and all the ways that could cause confusion
> in a way to make the pointer vanish.

maybe https://gitlab.freedesktop.org/spice/spice-gtk/issues/83 or related to
it.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [PSA] %meson contains -Db_ndebug=true

[Peter Hutterer]

On Mon, Apr 08, 2019 at 01:26:47PM +0200, Igor Gnatenko wrote:
> Ok, I have reverted change:
> 
> * https://bodhi.fedoraproject.org/updates/FEDORA-2019-42ea21c6e4
> * https://bodhi.fedoraproject.org/updates/FEDORA-2019-660ccd306c
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-eb940f069c
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-d229ead72a
> * https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2019-9f6eea54fe

thanks!

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: [PSA] %meson contains -Db_ndebug=true

[Peter Hutterer]

On Mon, Apr 08, 2019 at 09:20:35AM +0200, Igor Gnatenko wrote:
> Hello,
> 
> While fixing mesa build which was slow due to a lot off debug stuff
> (assert()), I've added -Db_ndebug=true into the %meson macro.
> 
> This seemed like good approach because in Fedora we should not use debug
> bits in runtime (not related to debuginfo). However this caused some
> breakage in some packages like libratbag which was relying on assert() in
> tests. This should be really fixed in affected packages..
> 
> I am not convinced that we should revert meson change.. Let me know if you
> think otherwise and why.

IMO if asserts cause a slow build in mesa, mesa should disable asserts.

Pushing this into the build system means you're changing the behaviour of
every package build with meson. I rely on asserts in several packages for
paths that must not happen - removing those asserts means instead of
crashing we now have undefined behaviour, probably leaking things.

NDEBUG is on the same level as _GNU_SOURCE, it significantly changes the
behaviour. Please leave it to packages to decide whether it should be set.

Cheers,
   Peter


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Can we please stop enforcing Signed-off-by commits?

[Peter Hutterer]

On Fri, Jan 18, 2019 at 09:07:19AM +, Richard W.M. Jones wrote:
> On Thu, Jan 17, 2019 at 06:20:00PM +0100, Miro Hrončok wrote:
> > "All commits must be signed-off on. Please use git commit -s to do
> 
> TIL - there's a git feature for adding S-o-B to a commit.
> I always typed it out by hand ...

unrelated: installing vim's snipMate helps with that, you can expand typing
"sobme" to be your full SOB line. Or anything else, really.

literally seconds shaved off your typing time! :)

$ cat $HOME/.vim/snippets/gitcommit.snippets
snippet ack
Acked-by:
snippet rev
Reviewed-by:
snippet sob
Signed-off-by:
snippet tested
    Tested-by:
snippet me
Peter Hutterer <...>
...

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Testing / feedback request: DNF 3 crashes

[Peter Hutterer]

On Tue, Sep 11, 2018 at 12:26:09PM -0700, Adam Williamson wrote:
> Hi folks!
> 
> Around the time DNF 3 landed in Rawhide (hence F29), we had quite a few
> folks on these lists reporting issues, including crasher bugs. Many of
> these seemed somehow related to the DNF history database. They also
> were not easy to isolate and fix.
> 
> We're now close to the F29 Beta release, but we don't have a great
> sense of how many people are still having these problems with DNF 3.2
> or 3.3.
> 
> Can anyone who is still struggling with DNF crashes on *basic*
> operations on F29 or Rawhide please reply, and provide a few details on
> what you're seeing and any workarounds or fixes you've found?
> 
> Thanks a lot!

fwiw, I just ran into https://bugzilla.redhat.com/show_bug.cgi?id=1632177
after a dnf system-upgrade and it crashed at least the dnf
history/update/remove commands (whenever it started dependency resolution):

Completion plugin: Generating completion cache...
--> Starting dependency resolution
zsh: segmentation fault  sudo dnf update --debuglevel 10

moving /var/lib/dnf out of the way fixed it but that's a less than polished
experience nonetheless ;)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

evemu license change

[Peter Hutterer]

Was a single package GPLv3+, is now split into a evemu-libs subpackage
LGPLv3+ and the evemu package (still GPLv3+).

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XPAZ3HCHI6UE7JIQ35765R35RZR6EAF5/

Re: gnome crashes after today upgrade

[Peter Hutterer]

On Wed, Feb 07, 2018 at 02:12:52PM +1000, Peter Hutterer wrote:
> xkeyboard-config-2.23.1-1.fc28 is building and seems to fix the issue
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24771380

First build failed, successful one is:
https://koji.fedoraproject.org/koji/taskinfo?taskID=24772701

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

[Peter Hutterer]

On Wed, Feb 07, 2018 at 12:42:54AM +, Tomasz Kłoczko wrote:
> On 6 February 2018 at 19:33, Bruno Wolff III  wrote:
> 
> > On Fri, Feb 02, 2018 at 20:35:25 +,
> >  Tomasz Kłoczko  wrote:
> >
> >> Hi,
> >>
> >> Looks like today updates are trashing gnome almost completely.
> >> gdm-x-session cannot setup XKB mapping. gnome-shell is core dumping ..
> >>
> >> "journalctl -xe" output is in attachment.
> >>
> >
> > If this is rawhide, you might try downgrading m17n-db* . On one machine
> > the latest version is causing lots of applications to crash. On other
> > machines it doesn't happen and I don't know what the difference is. I'm
> > hoping the gcc8 rebuild will fix things when it happens. Right now I don't
> > have much for the maintainer to go on to try to fix things.
> >
> 
> m17n-db has nothing to do with xkb.
> I've done something different.
> I found that m17n-db is only required by m17n-lib package and m17n-lib is
> required only by ibus-m17n, and nothing requires ibus-m17n.
> So I've removed all those three packages and after logout-> loging (under
> gnome or Xfce; both under X11) still gdm has been failing with *exactly*
> the same error messages.
> 
> xkb is about keyboard mappings withing working X11 server.
> 
> Nevertheless just found what is causing tose xkb errors.
> I've installed xorg-x11-xkb-extras to have the access to setxkbmap command
> and on executing:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> Error loading new keyboard description
> [tkloczko@domek ~]$ strace -e trace=file setxkbmap -v pl
> execve("/usr/bin/setxkbmap", ["setxkbmap", "-v", "pl"], 0x7ffcce6b2830 /*
> 46 vars */) = 0
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxkbfile.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libX11.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
> openat(AT_FDCWD, "/lib64/libXau.so.6", O_RDONLY|O_CLOEXEC) = 3
> access("/run/user/1000/gdm/Xauthority", R_OK) = 0
> openat(AT_FDCWD, "/run/user/1000/gdm/Xauthority", O_RDONLY) = 4
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> openat(AT_FDCWD, "./rules/evdev-C.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "./rules/evdev.lst", O_RDONLY) = -1 ENOENT (No such file
> or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C.lst", O_RDONLY) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev.lst", O_RDONLY) = 4
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev-C", O_RDONLY) = -1 ENOENT
> (No such file or directory)
> openat(AT_FDCWD, "/usr/share/X11/xkb/rules/evdev", O_RDONLY) = 4
> 
> Next was rpm query:
> 
> [tkloczko@domek ~]$ rpm -qif /usr/share/X11/xkb/rules/evdev
> Name: xkeyboard-config
> Version : 2.23
> Release : 1.fc28
> Architecture: noarch
> Install Date: Fri 02 Feb 2018 03:10:22 GMT
> Group   : Unspecified
> Size: 5804719
> License : MIT
> Signature   : RSA/SHA256, Wed 31 Jan 2018 09:07:03 GMT, Key ID
> e08e7e629db62fb1
> Source RPM  : xkeyboard-config-2.23-1.fc28.src.rpm
> Build Date  : Wed 31 Jan 2018 09:06:48 GMT   HERE 
> Build Host  : buildvm-ppc64le-15.ppc.fedoraproject.org
> Relocations : (not relocatable)
> Packager: Fedora Project
> Vendor  : Fedora Project
> URL : http://www.freedesktop.org/wiki/Software/XKeyboardConfig
> Summary : X Keyboard Extension configuration data
> Description :
> This package contains configuration data used by the X Keyboard Extension
> (XKB),
> which allows selection of keyboard layouts when using a graphical interface..
> 
> As long as upgrade 2.23 has been done around the time when mine problems
> with xkb started I've downloaded xkeyboard-config-2.22 from f27 and after
> downgrade:
> 
> [tkloczko@domek ~]$ setxkbmap -v pl
> Warning! Multiple definitions of keyboard layout
>  Using command line, ignoring X server
> Trying to build keymap using the following components:
> keycodes:   evdev+aliases(qwerty)
> types:  complete
> compat: complete
> symbols:pc+pl+inet(evdev)
> geometry:   pc(pc105)
> [tkloczko@domek ~]$ łóćźęśźż
> 
> So I'm able now to enter Polish characters :)
> 
> So looks like at least something is wrong with xkeyboard-config-2.23.

yep, thanks, there was a typo in the polish layout. Was fixed upstream, I
just don't 

Re: Wyland is a disaster

[Peter Hutterer]

On Wed, Jan 31, 2018 at 10:18:14PM +, Tomasz Kłoczko wrote:
> On 31 January 2018 at 22:09, Tomasz Kłoczko 
> wrote:
> [..]
> 
> > Why I think that it may be related to libinput? Because in logs I see as
> > well another type of entries:
> >
> > #  journalctl -xe | grep libinput
> > Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event5 debounce: offset negative (-354ms)
> > Jan 31 21:55:18 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event5 debounce short: offset negative (-368ms)
> > Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event5 debounce: offset negative (-1107ms)
> > Jan 31 21:56:27 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event5 debounce short: offset negative (-1120ms)
> > Jan 31 22:05:12 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event4 keyboard: offset negative (-331ms)
> > Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event4 keyboard: offset negative (-750ms)
> > Jan 31 22:06:05 domek org.gnome.Shell.desktop[2153]: libinput error:
> > libinput bug: timer event4 keyboard: offset negative (-413ms)

timer offset bugs almost always mean that libinput_dispatch() isn't called
quickly enough when its fd triggers. We rely on the compositor for that, so
you can blame gnome shell here.

Internally, libinput uses event timestamps and uses them for timers (e.g.
tap timer, debouncing, etc.). Let's assume an event happens, our timeout is
150ms but it takes 500ms after the event before calling libinput_dispatch(),
the timer offset is now 350ms in the past - that's what libinput warns about.

It's not a killer but it does mean that whatever libinput was trying to do
won't work correctly. In your case, the 'keyboard' timer is the one used in
disable-while-typing. So expect that not to work correctly.

Also: the keyboard timer is 500ms, and you have a neg. offset of 750ms. This
is a delay of 1250ms, that's crazy! Something's hogging gnome shell here and
it doesn't get to handle input.

> Correction:
> 
> # libinput list-devices | grep ^Device -A1
> Device:   Video Bus
> Kernel:   /dev/input/event7
> --
> Device:   Sony Vaio Jogdial
> Kernel:   /dev/input/event9
> --
> Device:   Sony Vaio Keys
> Kernel:   /dev/input/event8
> --
> Device:   Video Bus
> Kernel:   /dev/input/event6
> --
> Device:   Power Button
> Kernel:   /dev/input/event1
> --
> Device:   Lid Switch
> Kernel:   /dev/input/event0
> --
> Device:   USB 2.0 Camera: USB Camera
> Kernel:   /dev/input/event13
> --
> Device:   HDA Intel PCH Headphone
> Kernel:   /dev/input/event10
> --
> Device:   HDA Intel PCH HDMI/DP,pcm=3
> Kernel:   /dev/input/event11
> --
> Device:   HDA Intel PCH HDMI/DP,pcm=7
> Kernel:   /dev/input/event12
> --
> Device:   Logitech M185
> Kernel:   /dev/input/event5
> --
> Device:   CD002 CD002
> Kernel:   /dev/input/event3
> --
> Device:   AT Translated Set 2 keyboard
> Kernel:   /dev/input/event2
> --
> Device:   AlpsPS/2 ALPS GlidePoint
> Kernel:   /dev/input/event4
> 
> So event4 it is in my case touch pad and event5  it is Logitech M185 mouse.
> In other words: those "libinput bug" log entries looks like are not related
> to emitting those short bursts of repeating keystrokes.
 
not directly, but they indicate where the issue is: key repeat is handled in
the clients, not in libinput. With delays like this it's easy to see why you
would get key repeat - if your key release event is delayed by 300ms or more
the client will handle repeats before it gets the events.

But the real cause of the issue is that you're getting crazy delays because
gnome-shell is too busy with something else. The rest is fallout from that.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retiring Packages with Broken Dependencies in branched (2017-06-12)

[Peter Hutterer]

On Mon, Jun 12, 2017 at 03:47:48PM -0700, Josh Stone wrote:
> On 06/12/2017 03:38 PM, t...@fedoraproject.org wrote:
> > lldb   airlied, daveisfera,   71 weeks ago  
> >jankratochvil, jvcelak,  
> >siddharths, tstellar 
> 
> Where does that 71 weeks come from?  The lldb-3.9.1-4.fc26 reported
> below was just in March, not to mention lldb-4.0.0-1.fc26 on May 12.

not to mention that this lldb issue breaks rust which in turn breaks meson
which in turn breaks anything using meson. I'm going out on a limb here and
assume that packages using rust and meson are not necessarily EOL'd :)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad pointer accel - testers required, scratch build available

[Peter Hutterer]

On 25/02/2017 04:28 , Sylvia wrote:


Hi!

I'm using Wayland. Is it the same or should I do something different?


for wayland a simple restart of the compositor after installing libinput 
is enough. Same for X if you're using the xorg-x11-drv-libinput driver.


Cheers,
  Peter


On Fri, 2017-02-24 at 12:26 +1000, Peter Hutterer wrote:

On Thu, Feb 23, 2017 at 06:48:11PM -0600, Keith Keith wrote:

I think I sent you some touchpad data before for a Toshiba Tecra M11.
I have xorg-x11-drv-synaptics installed to keep my setup from F24. Do
I need to do anything besides get rid of
/etc/X11/xorg.conf.d/50-synaptics.conf and restart X to make this
work right?



yeah, that's all that should be needed. You can easily verify by running
xinput list-props "device name" afterwards and checking for the "libinput"
prefix on the properties.

Cheers,
   Peter


On Thu, Feb 23, 2017 at 5:35 PM, Peter Hutterer
<peter.hutte...@who-t.net <mailto:peter.hutte...@who-t.net>> wrote:

I've been playing with touchpad pointer acceleration in libinput
again and finally found something I'm happy with. Most notably it
has a wide range of configurable speed settings, from "tar" to
"speed-skating ring". Please give this scratch build a test and let
me know how you go:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245
Reminder: after installing you *must* log out of X/Wayland for the
changes to take effect. Thanks Cheers, Peter
___ devel mailing list
-- devel@lists.fedoraproject.org
<mailto:devel@lists.fedoraproject.org> To unsubscribe send an email
to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>




___ devel mailing list --
devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>


___
devel mailing list -- devel@lists.fedoraproject.org 
<mailto:devel@lists.fedoraproject.org>
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
<mailto:devel-le...@lists.fedoraproject.org>



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad pointer accel - testers required, scratch build available

[Peter Hutterer]

On Fri, Feb 24, 2017 at 03:08:22AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Feb 24, 2017 at 09:35:36AM +1000, Peter Hutterer wrote:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245
> 
> That seems to have expired.

doh, wrong link... sorry about that

https://koji.fedoraproject.org/koji/taskinfo?taskID=18007385

see also https://bugzilla.redhat.com/show_bug.cgi?id=1415793

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad pointer accel - testers required, scratch build available

[Peter Hutterer]

On Thu, Feb 23, 2017 at 06:48:11PM -0600, Keith Keith wrote:
> I think I sent you some touchpad data before for a Toshiba Tecra M11.  I
> have xorg-x11-drv-synaptics installed to keep my setup from F24. Do I need
> to do anything besides get rid of /etc/X11/xorg.conf.d/50-synaptics.conf
> and restart X to make this work right?

yeah, that's all that should be needed. You can easily verify by running
xinput list-props "device name" afterwards and checking for the "libinput"
prefix on the properties.

Cheers,
   Peter

> 
> On Thu, Feb 23, 2017 at 5:35 PM, Peter Hutterer <peter.hutte...@who-t.net>
> wrote:
> 
> > I've been playing with touchpad pointer acceleration in libinput again and
> > finally found something I'm happy with. Most notably it has a wide range of
> > configurable speed settings, from "tar" to "speed-skating ring". Please
> > give
> > this scratch build a test and let me know how you go:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245
> >
> > Reminder: after installing you *must* log out of X/Wayland for the changes
> > to take effect.
> >
> > Thanks
> >
> > Cheers,
> >Peter
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Touchpad pointer accel - testers required, scratch build available

[Peter Hutterer]

I've been playing with touchpad pointer acceleration in libinput again and
finally found something I'm happy with. Most notably it has a wide range of
configurable speed settings, from "tar" to "speed-skating ring". Please give
this scratch build a test and let me know how you go:
https://koji.fedoraproject.org/koji/taskinfo?taskID=17546245

Reminder: after installing you *must* log out of X/Wayland for the changes
to take effect.

Thanks

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

How to build both python 2 and 3 bindings from autotools?

[Peter Hutterer]

Before I start hacking up something nasty I figured it's better to ask: how
do I build both py2 and py3 bindings from a package using autotools (i.e.
AM_PATH_PYTHON)? 

So far my idea revolves around installing both python-devel packages and
overriding PYTHON in each %build , etc. But maybe there's a
simpler solution?

Package in question is evemu and yes, we are also the upstream maintainers
so if there's a more sensible solution we can move that into upstream.

Thanks

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Quality control, does it exist? A recent update removed a keyboard layout from system.

[Peter Hutterer]

On Mon, Dec 05, 2016 at 02:54:08AM +, Sérgio Basto wrote:
> On Dom, 2016-12-04 at 20:57 +, Iiro Laiho wrote:
> > The update FEDORA-2016-8dfffb0d43 to package xkeyboard-config removed
> > the Finnish (DAS) keyboard layout from the base.xml file. It causes
> > the keyboard layout in question suddenly disappearing from the system
> > without a trace when the unsuspecting user installs updates.
> > 
> > Is it really too much asked if developers would do diffs to files
> > they are changing when they do updates to critical components? It is
> > a very bad idea to simply update versions in already released distros
> > without paying a single thought to the regression potential.
> > 
> > The bug report of this issue is #1401327.
> 
> After waste sometime on understand what happened to Finnish keyboards
> layout, I don't think you can blame Fedora project, looking at upstream
> sources and releases [1] from xkeyboard-config-2.18 to 
> xkeyboard-config-2.19, we got one commit with "rules: Move Finnish DAS
> layout to extras", I understand you are angry (you lose keyboard
> layout) but also saw that layout just was added in 2015-09-29 [3] (
> xkeyboard-config-2.16 )
> You have some options , it might be interesting have extras layouts in
> Fedora , but I thin you should comment on upstream bugzilla with autor
> of the commits , the autor first add layout to xkeyboard-config and one
> year later move it to extras maybe he knows set keyboard with DAS
> layout in other way, for example also Indian layout has moved to extras
>  [4] says "For Indian languages, the input methods supplied by ibus-
> m17n  appear to be more useful" have you tried dnf install ibus-m17n ?
> and run ibus-setup ? 

it's a more convoluted problem. xkeyboard-config still ships the layout and
a call to setxkbmap for example still works. So would xorg.conf
configuration, because neither of those actually use the xml files. But it
looks like there's a bug in GNOME somewhere even when the layout is
preconfigured in gsettings it doesn't get applied anymore once moved to
extras. I haven't had time to trace that down, meanwhile that commit has
been reverted in F25.

fwiw, the indian language is a different issue, because those layouts are
apparently useless without ibus. the finnish one one (afaict) doesn't need
ibus to work so moving it to extras was done for different reasons.

Cheers,
   Peter

> 
> [1] 
> https://cgit.freedesktop.org/xkeyboard-config/log/
> [2] 
> http://c.seres.fi/DAS_en.html
> [3]
> https://cgit.freedesktop.org/xkeyboard-config/commit/?id=d9135dd2b4982ead857b5a4eb7065bf795ac2048
> [4]
> https://cgit.freedesktop.org/xkeyboard-config/commit/?id=913af7dafaab8ff4a9ae0d1e4c4097caf4a8022d
>  
> -- 
> Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad data needed - 5 min of effort

[Peter Hutterer]

On Fri, Nov 18, 2016 at 11:13:26PM +0100, Ms Sanchez wrote:
> 
> 
> On 18/11/16 19:53, Chris Murphy wrote:
> > On Fri, Nov 18, 2016 at 3:13 AM, Ms Sanchez  wrote:
> > > Hello Peter!
> > > 
> > > I tried to do this but it recorded nothing. Maybe I did something wrong?
> > Worked for me. But I did make modifications, I used tmux, because I'm
> > familiar with it, though that shouldn't matter, and I didn't literally
> > do this step:
> > 
> > $ sudo evemu-record > $HOME/touchpad-recording.evemu
> > 
> > Instead I did
> > 
> > $ sudo evemu-record > ~/touchpad-recording.evemu
> > 
> > One thing you may have not noticed is that after that command there's
> > a menu that appears and you have to find your trackpad device in that
> > menu list and choose it. Recording won't happen until you do this. You
> > can tail the file to check if it's recording trackpad data from that
> > point.
> > 
> > 
> 
> Yes, I chose the device but still nothing.  I'll try your suggestion and let
> you know what happened.

run it without the pipe into the file - do you see events appear at all when
you use the touchpad? If not, then you're using the wrong event node, just
try the others, one of them will send events. evemu is non-destructive, so
you can run it against any node, just dont record your keyboard, type a
password and then paste the output anywhere :)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad data needed - 5 min of effort

[Peter Hutterer]

On Tue, Nov 15, 2016 at 02:56:27PM -0500, Andrej Manduch wrote:
> Hi,
> 
> Here are my data: http://mysharegadget.com/104651530

got it, thanks.

Cheers,
   Peter

> 
> On 11/13/2016 10:20 PM, Peter Hutterer wrote:
> > [Disclaimer: sorry if you've seen this one before, I posted it to desktop@
> > but I only got one recording. That's not quite enough to call it a dataset,
> > let alone do any analysis on it. Please do consider the minimal effort
> > required on your behalf.]
> > 
> > Are you using a touchpad frequently during the day? Then please read on, I 
> > need
> > some touchpad usage data and it'll only take you 5 minutes to run the 
> > commands
> > below to gather the data.
> > 
> > If you're technical enough, here's the TLDR:
> > in screen, run sudo evemu-record > touchpad-recording.evemu, select your
> > touchpad device and at the end of the day upload a compressed tarball 
> > somewhere
> > and send me the link off-list. thanks.
> > 
> > Otherwise, the steps one-by-one:
> > 
> > Open a a terminal now, then install evemu:
> >$> sudo dnf install -y evemu screen
> > 
> > Then start screen:
> >$> screen -S evemu
> > 
> > Now you're inside screen and you can start the recording
> >$> sudo evemu-record > $HOME/touchpad-recording.evemu
> > 
> > One device will be a touchpad, named "SynPS/2 Synaptics Touchpad" or some 
> > other
> > name that should be identifiable. If you're on a late model Dell, it may be
> > named DLL0234 or something. Once you selected the device, evemu will start
> > recording.
> > 
> > Then hit Ctrl+a, then d to detach screen and return to the terminal.
> > 
> > Check that the recording works:
> >$> tail -f $HOME/touchpad-recording.evemu
> > 
> > Whenever you touch the touchpad, you should see events filling up the screen
> > now. If so, everything is working. Hit Ctrl+C to quit the 'tail' command. 
> > You
> > can close the terminal now.
> > 
> > The screen session will now sit in the background, recording all your 
> > touchpad
> > events into that file. At the end of the day:
> > 
> > First, open a terminal and restore the screen session:
> >$> screen -r evemu
> > 
> > Hit Ctrl+C to interrupt the evemu-record process, then type exit to quit
> > screen. Compress it first so it reduces in size a bit:
> > 
> >$> gzip $HOME/touchpad-recording.evemu
> > 
> > Now upload the newly created $HOME/touchpad-recording.evemu.gz file 
> > somewhere
> > and send me a off-list email with the link so I can grab it.
> > 
> > Thanks heaps.
> > 
> > As for "why" do I need this? I need it to analyse touchpad motion data to 
> > get
> > an idea of what range of finger motion speed is common and expected during
> > normal usage.
> > 
> > Cheers,
> >   Peter 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> 
> -- 
> Kind regards,
> b.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad data needed - 5 min of effort

[Peter Hutterer]

On Tue, Nov 15, 2016 at 12:03:32AM -0800, Thomas Daede wrote:
> Thinkpad W540, with two finger right click on (which I think is off by
> default):
> 
> https://people.xiph.org/~tdaede/w540.evemu.xz

got it, thanks.

Cheers,
   Peter

> On 11/13/2016 07:20 PM, Peter Hutterer wrote:
> > [Disclaimer: sorry if you've seen this one before, I posted it to desktop@
> > but I only got one recording. That's not quite enough to call it a dataset,
> > let alone do any analysis on it. Please do consider the minimal effort
> > required on your behalf.]
> > 
> > Are you using a touchpad frequently during the day? Then please read on, I 
> > need
> > some touchpad usage data and it'll only take you 5 minutes to run the 
> > commands
> > below to gather the data.
> > 
> > If you're technical enough, here's the TLDR:
> > in screen, run sudo evemu-record > touchpad-recording.evemu, select your
> > touchpad device and at the end of the day upload a compressed tarball 
> > somewhere
> > and send me the link off-list. thanks.
> > 
> > Otherwise, the steps one-by-one:
> > 
> > Open a a terminal now, then install evemu:
> >$> sudo dnf install -y evemu screen
> > 
> > Then start screen:
> >$> screen -S evemu
> > 
> > Now you're inside screen and you can start the recording
> >$> sudo evemu-record > $HOME/touchpad-recording.evemu
> > 
> > One device will be a touchpad, named "SynPS/2 Synaptics Touchpad" or some 
> > other
> > name that should be identifiable. If you're on a late model Dell, it may be
> > named DLL0234 or something. Once you selected the device, evemu will start
> > recording.
> > 
> > Then hit Ctrl+a, then d to detach screen and return to the terminal.
> > 
> > Check that the recording works:
> >$> tail -f $HOME/touchpad-recording.evemu
> > 
> > Whenever you touch the touchpad, you should see events filling up the screen
> > now. If so, everything is working. Hit Ctrl+C to quit the 'tail' command. 
> > You
> > can close the terminal now.
> > 
> > The screen session will now sit in the background, recording all your 
> > touchpad
> > events into that file. At the end of the day:
> > 
> > First, open a terminal and restore the screen session:
> >$> screen -r evemu
> > 
> > Hit Ctrl+C to interrupt the evemu-record process, then type exit to quit
> > screen. Compress it first so it reduces in size a bit:
> > 
> >$> gzip $HOME/touchpad-recording.evemu
> > 
> > Now upload the newly created $HOME/touchpad-recording.evemu.gz file 
> > somewhere
> > and send me a off-list email with the link so I can grab it.
> > 
> > Thanks heaps.
> > 
> > As for "why" do I need this? I need it to analyse touchpad motion data to 
> > get
> > an idea of what range of finger motion speed is common and expected during
> > normal usage.
> > 
> > Cheers,
> >   Peter 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad data needed - 5 min of effort

[Peter Hutterer]

On Mon, Nov 14, 2016 at 10:45:10AM -0500, Kamil Paral wrote:
> > [Disclaimer: sorry if you've seen this one before, I posted it to desktop@
> > but I only got one recording. That's not quite enough to call it a dataset,
> > let alone do any analysis on it. Please do consider the minimal effort
> > required on your behalf.]
> > 
> > Are you using a touchpad frequently during the day? Then please read on, I
> > need
> > some touchpad usage data and it'll only take you 5 minutes to run the
> > commands
> > below to gather the data.
> 
> Are you also interested in trackpoint data?

Not at this point, I can only focus on one thing at a time :)

More specifically: touchpad data is relatively easy to collect and analyse.
Trackpoint data is a lot more confusing and varied, so even to collect the
data in the first place I have to write a script that pulls in some other
information from the system. I'm not there yet, but if you're interested in
in working on trackpoint pointer acceleration in libinput, contact me
off-list please [1].

Cheers,
   Peter

[1] You'll get all the hate-mail you want, for free! :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Touchpad data report

[Peter Hutterer]

On Sun, Nov 13, 2016 at 07:40:21PM -0800, Luya Tshimbalanga wrote:
> Hi Peter,
> This is Luya Tshimbalanga, one of Fedora Design Team member. I am
> sending you the data you need.

thanks, much appreciated. I should've mentioned: please reply to me off-list
with the data, no need to load up devel@ with too many attachments :)

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Touchpad data needed - 5 min of effort

[Peter Hutterer]

[Disclaimer: sorry if you've seen this one before, I posted it to desktop@
but I only got one recording. That's not quite enough to call it a dataset,
let alone do any analysis on it. Please do consider the minimal effort
required on your behalf.]

Are you using a touchpad frequently during the day? Then please read on, I need
some touchpad usage data and it'll only take you 5 minutes to run the commands
below to gather the data.

If you're technical enough, here's the TLDR:
in screen, run sudo evemu-record > touchpad-recording.evemu, select your
touchpad device and at the end of the day upload a compressed tarball somewhere
and send me the link off-list. thanks.

Otherwise, the steps one-by-one:

Open a a terminal now, then install evemu:
   $> sudo dnf install -y evemu screen

Then start screen:
   $> screen -S evemu

Now you're inside screen and you can start the recording
   $> sudo evemu-record > $HOME/touchpad-recording.evemu

One device will be a touchpad, named "SynPS/2 Synaptics Touchpad" or some other
name that should be identifiable. If you're on a late model Dell, it may be
named DLL0234 or something. Once you selected the device, evemu will start
recording.

Then hit Ctrl+a, then d to detach screen and return to the terminal.

Check that the recording works:
   $> tail -f $HOME/touchpad-recording.evemu

Whenever you touch the touchpad, you should see events filling up the screen
now. If so, everything is working. Hit Ctrl+C to quit the 'tail' command. You
can close the terminal now.

The screen session will now sit in the background, recording all your touchpad
events into that file. At the end of the day:

First, open a terminal and restore the screen session:
   $> screen -r evemu

Hit Ctrl+C to interrupt the evemu-record process, then type exit to quit
screen. Compress it first so it reduces in size a bit:

   $> gzip $HOME/touchpad-recording.evemu

Now upload the newly created $HOME/touchpad-recording.evemu.gz file somewhere
and send me a off-list email with the link so I can grab it.

Thanks heaps.

As for "why" do I need this? I need it to analyse touchpad motion data to get
an idea of what range of finger motion speed is common and expected during
normal usage.

Cheers,
  Peter 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Retire Synaptics Driver

[Peter Hutterer]

On Fri, Oct 21, 2016 at 01:24:22AM +0200, Kevin Kofler wrote:
> Jan Kurik wrote:
> > - Affected packages: mate-desktop, cinnamon-desktop
> 
> For what it's worth, while it is not a hard runtime dependency (nor even 
> listed as a soft dependency in the package) because libinput is also 
> supported, the kcm_touchpad in plasma-desktop is much more functional with 
> the synaptics driver (and this is not likely to change any time soon, given 
> that libinput just removed most of the settings). So this change will also 
> affect some Plasma users, though not necessarily in a bad way (as the intent 
> is to make it easier to install the driver when wanted).
> 
> plasma-desktop also requires xorg-x11-drv-synaptics-devel (in particular, 
> the  header, for constant definitions) at build 
> time, is that package name going to change?

I was planning to leave the -devel package name as-is, I don't think
renaming it provides any benefit.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Retire Synaptics Driver

[Peter Hutterer]

On Thu, Oct 20, 2016 at 08:16:21PM -, Johannes Lips wrote:
> > On Thu, 20 Oct 2016 10:08:29 +0200
> > Johannes Lips  > 
> > 
> > Can you expand on how/what didn't work here?
> > 
> > I've been using it here with Xfce just fine since support was added...
> > no particular problems here. 
> Hi Kevin,
> I think I was affected by this bug, basically natural scrolling was different 
> across the gtk toolkits.
> https://bugzilla.xfce.org/show_bug.cgi?id=11193

that sounds... odd. when libinput enables natural scrolling, the scroll
events coming out of the driver are already inverted. The toolkits don't get
a say in that and it should be completely transparent anyway.

Cheers,
   Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24, small backward steps

[Peter Hutterer]

On Fri, Sep 09, 2016 at 03:53:06PM -0400, Roger Wells wrote:
> Just a couple of smallish things after upgrading (via dnf) from F23 to
> F24 a couple of months ago:
> 
> 1. deja-dup gui:
> 
> one has to deselect then reselect the Overview option in order
> to be offered the "Backup Now" option.
> 
> The details option in the progress dialog will only display two
> or three lines, is not resizeable, and does not follow resizing the
> entire dialog
> 
> The progress dialog does not wait to be dismissed at the end,
> causing any messages about problems (like failure to backup a particular
> file) to not be seen
> 
> 2. fingerprint identification:
> 
> The laptop has a fingerprint reader and it works fine.  However
> I prefer not to use it. The user set up specifies that fingerprint login
> is disabled.
> 
> However whenever I am asked for a password the fingerprint
> reader blinks until I swipe a finger over it (even after using a
> password). 
> 
> No fingerprint is registered.
> 
> This is different than F23 where it never blinked.
> 
> 3. Scrolling issues:
> 
> This, edge and natural scrolling via the touchpad, was covered
> nicely in a previous thread. 
> 
> Solutions offered there work well but should be better
> integrated as I am sure they will be.

what was the problem here? can you point me to the original thread?

Cheers,
   Peter
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Update libinput 1.3.0 in Fedora 23

[Peter Hutterer]

On Tue, May 10, 2016 at 08:45:14PM -, jack smith wrote:
> Hello,
> 
> Can libinput 1.3.0 be updated in Fedora 23 please, to enjoy this "fix" :
> 
> https://cgit.freedesktop.org/wayland/libinput/commit/?id=6a22eed4efa2a18664d62c6d8131c05258f869ab

please file a bug report and assign it to me. I haven't decided yet whether
I'll backport the workaround or update to 1.3 but having a bug makes things
easier.

Cheers,
   Peter
 
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: libinput soname bump

[Peter Hutterer]

On Tue, Mar 10, 2015 at 03:37:48PM +1000, Peter Hutterer wrote:
 libinput 0.12 had a soname bump. I've rebuilt weston, clutter, mutter,
 xorg-x11-drv-libinput in rawhide, the F22 packages will follow tomorrow.

done, bodhi update is here:
https://admin.fedoraproject.org/updates/mutter-3.15.91-2.fc22,xorg-x11-drv-libinput-0.8.0-2.fc22,clutter-1.21.6-2.fc22,weston-1.7.0-2.fc22,libinput-0.12.0-1.fc22

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libinput soname bump

[Peter Hutterer]

libinput 0.12 had a soname bump. I've rebuilt weston, clutter, mutter,
xorg-x11-drv-libinput in rawhide, the F22 packages will follow tomorrow.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Mon, Mar 02, 2015 at 03:03:06PM +0100, drago01 wrote:
 On Mon, Mar 2, 2015 at 1:32 AM, Peter Hutterer peter.hutte...@who-t.net 
 wrote:
  On Thu, Feb 26, 2015 at 09:49:48AM +0100, Hans de Goede wrote:
  Hi,
 
  On 24-02-15 18:34, drago01 wrote:
  On Mon, Feb 23, 2015 at 1:32 PM, Hans de Goede hdego...@redhat.com 
  wrote:
  Hi All,
  
  As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
  
  We've been working on making xorg-x11-drv-libinput the default input 
  driver
  for the Xorg xserver under Fedora 22. All the necessary changes for this 
  are
  in place for the GNOME and KDE desktops. So starting with the next 
  Fedora 22
  compose new Fedora 22 Workstation installations will be using
  xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.
  
  For existing installations the move to libinput will not happen
  automatically, as  we have not added a hard dependency on
  xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the 
  old
  drivers until they have adopted their mouse/touchpad configuration 
  settings
  tools to also work with xorg-x11-drv-libinput.
  
  If you're running F-22 with GNOME or KDE, please do the following to 
  switch
  to the new driver:
  
  sudo dnf install xorg-x11-drv-libinput
  
  And let us know if you experience any issues while using the new driver.
  
  So we'd have two sets of users ... those who upgraded and those how
  reinstalled running different drivers for the same hardware?
 
  Yes, we need to maintain both stacks for a while anyways for e.g. lxde 
  users,
  etc. Given that XFCE now supports libinput too, we could reconsider this
  and make xorg-drv-libinput a hard dep of the X server so that everyone gets
  it, but officially we are past the end of the feature merge window.
 
  Peter, any thoughts on this ?
 
  not this cycle, IMO. there are some behaviour changes between
  evdev/synaptics and libinput. That's fine for a new install, but changing
  that on update can be considered a regression for some. At least
  for F22 I think we should leave things as is.
 
 Well going by the workstation PRD:
 
 Upgrading the system multiple times through the upgrade process
 should give *a result that is the same as an original install of
 Fedora Workstation*. [...] 
 (https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Overall_plans_and_policies_for_the_product)
 
 if it is good enough for new installs it is good enough for upgrades.

this is where it gets a bit complicated. evdev and synaptics are the current
default drivers. xlibinput is the new default. 
[xlibinput here meaning xorg-x11-drv-libinput, I'm lazy today]

default means two things: what we install and what the server will pick
for each specific device. the latter is decided by xorg.conf.d snippets that
we ship with the drivers. xlibinput simply sorts later than evdev/synaptics
and can thus override the selections of others.

to switch to xlibinput on upgrade we have to somehow force the xlibinput
driver onto their systems. Can be done with a Provides/Obsoletes but the
xlibinput driver is simply not the same as evdev/synaptics so that's
questionable to begin with.

Besides, this can seriously break local configuration, if you have an
/etc/X11/xorg.conf.d snippet that assigns the evdev driver this will
override the distro-shipped xlibinput assignment. if we remove the
evdev/synaptics drivers on upgrade this will leave the user with no input
devices.

I don't have a good solution to this, tbh, at least nothing short of
trawling the system for xorg.conf.d snippets and guessing what will
eventually apply on server start. and that's not a good idea, for all the
obvious reasons.

The upstream long-term solution is likely to merge xlibinput into the server
so we always have a fallback driver. Then if evdev isn't there we can still
fall back onto libinput. We're not there yet though and likely won't be for
the next cycle.

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Thu, Feb 26, 2015 at 09:49:48AM +0100, Hans de Goede wrote:
 Hi,
 
 On 24-02-15 18:34, drago01 wrote:
 On Mon, Feb 23, 2015 at 1:32 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi All,
 
 As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
 
 We've been working on making xorg-x11-drv-libinput the default input driver
 for the Xorg xserver under Fedora 22. All the necessary changes for this are
 in place for the GNOME and KDE desktops. So starting with the next Fedora 22
 compose new Fedora 22 Workstation installations will be using
 xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.
 
 For existing installations the move to libinput will not happen
 automatically, as  we have not added a hard dependency on
 xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old
 drivers until they have adopted their mouse/touchpad configuration settings
 tools to also work with xorg-x11-drv-libinput.
 
 If you're running F-22 with GNOME or KDE, please do the following to switch
 to the new driver:
 
 sudo dnf install xorg-x11-drv-libinput
 
 And let us know if you experience any issues while using the new driver.
 
 So we'd have two sets of users ... those who upgraded and those how
 reinstalled running different drivers for the same hardware?
 
 Yes, we need to maintain both stacks for a while anyways for e.g. lxde users,
 etc. Given that XFCE now supports libinput too, we could reconsider this
 and make xorg-drv-libinput a hard dep of the X server so that everyone gets
 it, but officially we are past the end of the feature merge window.
 
 Peter, any thoughts on this ?

not this cycle, IMO. there are some behaviour changes between
evdev/synaptics and libinput. That's fine for a new install, but changing
that on update can be considered a regression for some. At least
for F22 I think we should leave things as is.

It's a lot of new code too, one cycle should help iron out the common bugs.
For F23 dropping evdev and synaptics by default is fine.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Tue, Feb 24, 2015 at 07:58:06PM +0100, Tomasz Torcz wrote:
 On Mon, Feb 23, 2015 at 01:32:29PM +0100, Hans de Goede wrote:
  And let us know if you experience any issues while using the new driver.
 
   Do you prefer email, RH bugzilla or freedesktop bugzilla?
 Because (win)logo key + middle mouse click stopped working for
 window resize. Logo key + left mouse still work for window move.

if you have an fdo account, please file the bug there, it's easier to track
and close.

Also, fwiw, I expect most bugs that aren't crashers to be libinput bugs, the
xorg libinput driver is quite a thin wrapper.

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Mon, Feb 23, 2015 at 01:40:23PM +0100, Vít Ondruch wrote:
 Dne 23.2.2015 v 13:39 Vít Ondruch napsal(a):
  Dne 23.2.2015 v 13:32 Hans de Goede napsal(a):
  Hi All,
 
  As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
 
  We've been working on making xorg-x11-drv-libinput the default input
  driver for the Xorg xserver under Fedora 22. All the necessary changes
  for this are in place for the GNOME and KDE desktops. So starting with
  the next Fedora 22 compose new Fedora 22 Workstation installations
  will be using xorg-x11-drv-libinput instead of the -evdev and
  -synaptics drivers.
 
  For existing installations the move to libinput will not happen
  automatically, as  we have not added a hard dependency on
  xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the
  old drivers until they have adopted their mouse/touchpad configuration
  settings tools to also work with xorg-x11-drv-libinput.
 
  If you're running F-22 with GNOME or KDE, please do the following to
  switch to the new driver:
 
  sudo dnf install xorg-x11-drv-libinput
  Is it correct to assume that for GNOME and KDE, you can follow with:
 
  sudo dnf remove xorg-x11-drv-{evdev,synaptics}
 
 And probably wacom as well?

No, we don't handle tablets in libinput yet, pls leave wacom in place for
now. 

besides, transparently replacing the wacom driver is a bit more complicated
as clients rely a lot more on specific quirks of that driver than
evdev/synaptics.

Cheers,
   Peter

 
  I did that and everything seems to work just fine.
 
  Also, I can't see such change reflected in comps (yet?).
 
 
  Vít
 
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Libinput now enabled as default xorg driver for F-22 workstation installs

[Peter Hutterer]

On Mon, Feb 23, 2015 at 07:54:55PM +0100, poma wrote:
 On 23.02.2015 13:32, Hans de Goede wrote:
  Hi All,
  
  As described here: https://fedoraproject.org/wiki/Changes/LibinputForXorg
  
  We've been working on making xorg-x11-drv-libinput the default input driver 
  for the Xorg xserver under Fedora 22. All the necessary changes for this 
  are in place for the GNOME and KDE desktops. So starting with the next 
  Fedora 22 compose new Fedora 22 Workstation installations will be using 
  xorg-x11-drv-libinput instead of the -evdev and -synaptics drivers.
  
  For existing installations the move to libinput will not happen 
  automatically, as  we have not added a hard dependency on 
  xorg-x11-drv-libinput so the XFCE, LXDE, etc. spins can keep using the old 
  drivers until they have adopted their mouse/touchpad configuration settings 
  tools to also work with xorg-x11-drv-libinput.
 
 ANNOUNCE: xfce4-settings 4.11.4 released
 https://mail.xfce.org/pipermail/xfce-announce/2015-February/000358.html
 - Add touchpad support with libinput
 - Add support for libinput Xorg driver (bug #11469)
 
 Soon as part of the
 __  __ ___  __   
 \ \/ // _| ___ ___  | || |  / |___ \ 
  \  /| |_ / __/ _ \ | || |_ | | __) |
  /  \|  _| (_|  __/ |__   _|| |/ __/ 
 /_/\_\_|  \___\___||_|(_)_|_|
  
 
 
  
  If you're running F-22 with GNOME or KDE, please do the following to switch 
  to the new driver:
  
  sudo dnf install xorg-x11-drv-libinput
  
 
 What is this strange command sudo dnf!?
 
 Maybe you are thinking of
 $ pkexec yum install xorg-x11-drv-libinput
 
  And let us know if you experience any issues while using the new driver.
  
 
 Sure, can you explain me how to adjust
 Option VelocityScale
 via 'xorg-x11-drv-libinput'?

Option AccelSpeed value, range is -1.0 to +1.0, default is 0. Property
name is libinput Accel Speed.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: another input/output question (libinput / pulseaudio / ....)

[Peter Hutterer]

On Tue, Feb 10, 2015 at 02:09:55PM -0500, Matthias Clasen wrote:
 On Mon, 2015-02-09 at 08:44 +1000, Peter Hutterer wrote:
 
  However, especially for libinput, it gets hazy and also mostly pointless.
  aside from some special processing required for touchpads and tablets, we
  don't care much _what_ a device is, we just pass on the events.  If a device
  has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the
  compositor/X stack will then handle that however need be. There's no real
  benefit to us trying to figure out what is a headset and what isn't, we'd
  still just pass on the keys.
 
 Fair enough. One thing that is important, though, is to preserve enough
 information about the originating device (and the general device
 topology) that higher levels have a chance to do the right thing (e.g.
 mute the headset and not the speakers, if that is where the mute button
 is).

I _think_ we do that but I'm open to suggestions if we don't do it
sufficiently.
First, all events in libinput are device-based. There are some seat helpers
but all events are still per libinput device, so you definitely know which
device the event is coming from.

Right now, the only real thing to associate with any topology you get from
libinput is the udev_device. What's in the works for 0.11 are device groups
(see http://who-t.blogspot.com.au/2015/02/libinput-device-groups.html) which
give you a bit more of the topology in some special cases, though that
probably won't apply in this particular case.

if there is anything more we should do pls let us know.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: another input/output question (libinput / pulseaudio / ....)

[Peter Hutterer]

On Fri, Feb 06, 2015 at 11:47:16AM +0100, Damian Ivanov wrote:
 Hello folks,
 
 I am happy owner of a Razer 7.1 Chroma Headset (my girlfriend makes
 the right presents :))
 
 There are various issues with this product as well as with some
 devices in general.
 I can of course open separate bug reports for each issue (if needed)
 
 1) As I tried rawhide today with xorg-x11-drv-libinput I noticed that
 the Headset is listed as input device
 type: keyboard;map:us;
 I guess that's because it has a mute button on the retractable micro
 (suggestion: libinput type:headset??)

X itself doesn't know about anything but pointers and keyboards (after all,
they comprised the vast majority of devices in the 80s :) So the best you
can expect here is a different log message.

However, especially for libinput, it gets hazy and also mostly pointless.
aside from some special processing required for touchpads and tablets, we
don't care much _what_ a device is, we just pass on the events.  If a device
has keys, it'll be a keyboard. if it sents KEY_MUTE we pass that on, the
compositor/X stack will then handle that however need be. There's no real
benefit to us trying to figure out what is a headset and what isn't, we'd
still just pass on the keys.

Cheers,
   Peter

 2) In the sound settings it's only stereo listed as profile, it's a 7.1 
 headset
 (yes, I tried it on Windows and 7.1 headset is not only snake oil)
 It is really poorly documented how to get 7.1 working.
 
 3) The chroma (razer) device series (keyboards,mice,headsets and others)
  have Led's on it which can change the color using the windows driver.
  The Led's work on Linux but there is no tool to change it.
  The chroma series are only the first of this type, more products from
   other companies seem to have/get such feature as well.
   If there was a backend that does changing the color is there any
 place in the  gnome ui, where this could be placed (the chroma
 devices has mice/headsets/keyboards)?
 I have seen using wireshark and a VM how to reverse engineer what the
 driver does when changing the color. Question here: where would this
 go?
 A cmd tool? A seperate gui tools? Can this and if yes how be
 integrated to gnome-control-center?
 
 Thanks in advance for any input/output :)
 
 br,
 Damian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: xorg libinput question

[Peter Hutterer]

On Thu, Feb 05, 2015 at 10:34:49PM +0200, Damian Ivanov wrote:
 ok so I tried it - does NOT work ;
 1) Did a fresh rawhide install as update did not work.
 2) Installed xorg-x11-drv-libinput and installed wacom/synaptics/evdev
 3) put
 Section InputClass
 Identifier libinput
 Driver libinput
 MatchDevicePath /dev/input/event*
 EndSection
 in /etc/xorg.conf.d/
 
 4) connected wiimote via bluetooth
 5) no keys are recognized or configured
 
 So how to I configure wiimote + it's accessories (nunchuk and classic
 controller) with libinput driver?

did not work is a bit hard to debug, I need an xorg.log, evemu-record from
the wiimote, etc. Please file a bug in the freedesktop bugzilla, then we can
figure out what exactly is going on here.

Cheers,
   Peter

 2015-02-05 14:10 GMT+02:00 Damian Ivanov damianator...@gmail.com:
  Thanks for the quick answer! Upgrading to rawhide to try it out then :)
  In the changelog http://koji.fedoraproject.org/koji/buildinfo?buildID=606678
  * Mon Nov 24 2014 Peter Hutterer peter.hutte...@redhat.com 0.2.0-1 -
  Only match on specific device types, don't match on joysticks or
  tablets
 
  That sounded like it won't work with the xorg libinput driver.
  Are there any configuration option I can try?
  Do you know if the accessories like classic controller and nunchuk
  work? - I will see that anyway in a few minutes I guess
 
  2015-02-05 11:59 GMT+01:00 Peter Hutterer peter.hutte...@who-t.net:
  On Thu, Feb 05, 2015 at 11:25:25AM +0100, Damian Ivanov wrote:
  According to https://github.com/dvdhrm/xf86-input-xwiimote/issues/18
  the wiimote will work with wayland-libinput.
 
  My question is does this work do xorg-input-drv-libinput?
 
  the X driver is just a thin wrapper around libinput, it doesn't do much
  other than forwarding events. so yes, it should work.
 
  Cheers,
 Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: xorg libinput question

[Peter Hutterer]

On Fri, Feb 06, 2015 at 12:19:34AM +0200, Damian Ivanov wrote:
 Sure, I will provide you with the needed logs.
 Can you give me a hint to which product to report the bug to?

https://bugs.freedesktop.org/enter_bug.cgi?product=Waylandcomponent=libinput

 Also for the evemu record I'm not sure which device corresponds to the
 wiimote and/or attached accessories. Where can I find this?

if you run evemu-record without arguments it'll give you the list of local
devices, just pick the one that looks like a wiimote.

Cheers,
   Peter

 2015-02-05 23:01 GMT+02:00 Peter Hutterer peter.hutte...@who-t.net:
  On Thu, Feb 05, 2015 at 10:34:49PM +0200, Damian Ivanov wrote:
  ok so I tried it - does NOT work ;
  1) Did a fresh rawhide install as update did not work.
  2) Installed xorg-x11-drv-libinput and installed wacom/synaptics/evdev
  3) put
  Section InputClass
  Identifier libinput
  Driver libinput
  MatchDevicePath /dev/input/event*
  EndSection
  in /etc/xorg.conf.d/
 
  4) connected wiimote via bluetooth
  5) no keys are recognized or configured
 
  So how to I configure wiimote + it's accessories (nunchuk and classic
  controller) with libinput driver?
 
  did not work is a bit hard to debug, I need an xorg.log, evemu-record from
  the wiimote, etc. Please file a bug in the freedesktop bugzilla, then we can
  figure out what exactly is going on here.
 
  Cheers,
 Peter
 
  2015-02-05 14:10 GMT+02:00 Damian Ivanov damianator...@gmail.com:
   Thanks for the quick answer! Upgrading to rawhide to try it out then :)
   In the changelog 
   http://koji.fedoraproject.org/koji/buildinfo?buildID=606678
   * Mon Nov 24 2014 Peter Hutterer peter.hutte...@redhat.com 0.2.0-1 -
   Only match on specific device types, don't match on joysticks or
   tablets
  
   That sounded like it won't work with the xorg libinput driver.
   Are there any configuration option I can try?
   Do you know if the accessories like classic controller and nunchuk
   work? - I will see that anyway in a few minutes I guess
  
   2015-02-05 11:59 GMT+01:00 Peter Hutterer peter.hutte...@who-t.net:
   On Thu, Feb 05, 2015 at 11:25:25AM +0100, Damian Ivanov wrote:
   According to https://github.com/dvdhrm/xf86-input-xwiimote/issues/18
   the wiimote will work with wayland-libinput.
  
   My question is does this work do xorg-input-drv-libinput?
  
   the X driver is just a thin wrapper around libinput, it doesn't do much
   other than forwarding events. so yes, it should work.
  
   Cheers,
  Peter
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: xorg libinput question

[Peter Hutterer]

On Thu, Feb 05, 2015 at 11:25:25AM +0100, Damian Ivanov wrote:
 According to https://github.com/dvdhrm/xf86-input-xwiimote/issues/18
 the wiimote will work with wayland-libinput.
 
 My question is does this work do xorg-input-drv-libinput?

the X driver is just a thin wrapper around libinput, it doesn't do much
other than forwarding events. so yes, it should work.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Testers needed: KDE kcm_touchpad libinput support

[Peter Hutterer]

On Sun, Feb 01, 2015 at 10:15:08PM +0100, Rajeesh K V wrote:
 On Thu, Jan 22, 2015 at 7:45 AM, Peter Hutterer
 peter.hutte...@who-t.net wrote:
  Please add this copr
  https://copr.fedoraproject.org/coprs/whot/kcm_touchpad/
 
 KF5 based builds with libinput support are available in the copr
 http://copr.fedoraproject.org/coprs/rajeeshknambiar/kf5-kde-apps/

Thank Rajeesh, much appreciated!

Unless there are disasterous issues with these, we'll pull the switch for
rawhide very soon and switch to the libinput xorg driver as default driver.
So if you're on KDE it's in your interest to try these out.

Cheers,
   Peter
 
 
  Please review this branch:
  https://github.com/whot/kcm_touchpad/tree/wip/libinput-support
 
  Please test this on F21 and F22
 
  Please monitor and report issues in this bug here:
  https://bugzilla.redhat.com/show_bug.cgi?id=1184713
 
  Please send beer. No? oh well, was worth a try... :)
 
  Anwyay, I've tested this on F21 and with xorg/libinput bits equiv to
  rawhide and it works for both. As I point out in the bug:
  Note that we need to keep supporting both synaptics and libinput. libinput
  has less knobs to tweak, so a large portion of the UI is now disabled.
  Long-term upstream KDE should reconsider the design of the kcm_touchpad
  module to accommodate for both drivers, but for now I think this will do.
 
  Also note that disable-while-typing is disabled because libinput does it
  automatically (or something very similar anyway).
 
  Also note that the Fedora 20 libinput version does not support switching
  scroll methods, so that'll be permanently disabled in the GUI (but enabled
  on the touchpad). And edge scrolling is only available on single-touch
  touchpads, so that's permanently disabled in the GUI too.
 
  So this is the classic 90% case to make things work. A bit of polish is
  needed but I'd like for upstream to help out with that.
 
  Cheers,
 Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packages without the Rawhide branch?

[Peter Hutterer]

On Thu, Jan 29, 2015 at 01:04:34AM +0100, Matěj Cepl wrote:
 On 2015-01-28, 21:10 GMT, Kevin Fenzi wrote:
  I have just created (and got approved) python-mako1.0 as 
  a compatibility package for EPEL-6. When I asked for the new 
  repo for it, I expect to get also devel/Rawhide branch for it.  
  However, I don't see any purpose of it. Should I just orphan the 
  devel branch of it? Or is there a way how to get a package 
  without it in the first place? Shouldn't it be possible?
 
  Yes, just retire and add a dead.package the devel branch. 
 
  There's no better way to do this currently.
 
 And couldn't we make the script which builds the repos 
 understand some syntax extension to do it? E.g., what about
 
 New Package SCM Request
 ===
 Package Name: foo
 Short Description: fobricates bar
 Upstream URL: http://pkgname-project.org/pkgname
 Owners: jdoe
 Branches: el6 epel7 -devel
 InitialCC:
 
 Perhaps it would do just the retirement of devel branch.
 
 What about that?

I don't have numbers on how many packages have this need but I predict that
the efforts to get this to work, test it, deploy it, etc. are vastly greater
than the time saved not having to retire a package :)

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Testers needed: KDE kcm_touchpad libinput support

[Peter Hutterer]

Please add this copr
https://copr.fedoraproject.org/coprs/whot/kcm_touchpad/

Please review this branch:
https://github.com/whot/kcm_touchpad/tree/wip/libinput-support

Please test this on F21 and F22

Please monitor and report issues in this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1184713

Please send beer. No? oh well, was worth a try... :)

Anwyay, I've tested this on F21 and with xorg/libinput bits equiv to
rawhide and it works for both. As I point out in the bug: 
Note that we need to keep supporting both synaptics and libinput. libinput
has less knobs to tweak, so a large portion of the UI is now disabled.
Long-term upstream KDE should reconsider the design of the kcm_touchpad
module to accommodate for both drivers, but for now I think this will do.

Also note that disable-while-typing is disabled because libinput does it
automatically (or something very similar anyway).

Also note that the Fedora 20 libinput version does not support switching
scroll methods, so that'll be permanently disabled in the GUI (but enabled
on the touchpad). And edge scrolling is only available on single-touch
touchpads, so that's permanently disabled in the GUI too.

So this is the classic 90% case to make things work. A bit of polish is
needed but I'd like for upstream to help out with that.

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libinput soname bump

[Peter Hutterer]

libinput 0.8 had a soname bump and some API changes.
I've pushed the required patches and rebuilt the following packages in
rawhide for clutter, mutter, weston, and xorg-x11-drv-libinput.

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Summary/Minutes from today's FESCo Meeting (2015-01-07)

[Peter Hutterer]

On Thu, Jan 08, 2015 at 11:50:54AM -0500, Miloslav Trmač wrote:
  Dne 7.1.2015 v 21:14 Stephen Gallagher napsal(a):
* #1379 F22 System Wide Change: Change xorg input stack to use libinput
 - https://fedoraproject.org/wiki/Changes/LibinputForXorg  (sgallagh,
  19:51:28)
  * AGREED: Approved with two caveats: 1) Both GNOME and KDE must be
updated by the contingency date or it goes into effect and 2) the
contingency plan should note that it will may require reverting
changes to the control panels as well. (+7, 0, -0)  (sgallagh,
19:57:46)
  
  Thanks!
  
  WRT to the 2 caveats:
  
  1) As mentioned in the feature page KDE does not need any changes since
  its mouse settings panel does not talk directly to low level Xorg drivers.
 
 
 Quoting Kevin Kofler:
  We ship kcm_touchpad on the KDE spin, which definitely does depend
  on synaptics interfaces (search for synaptics in:
  https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp
   ).
  Anything that does not use the synaptics driver is not considered a
  touchpad. And kcm_touchpad is also in the process of becoming a core part of
  upstream Plasma. (It is currently in the git.kde.org playground.)
  
  Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
  not the old, obsolete, 0.3.x version, please make sure you look at the
  correct version) is an essential requirement before we can move away from
  the synaptics driver.
 
 I don’t claim to know enough whether this is an “essential requirement”
 but it does seem like something to discuss and agree on with the KDE
 maintainers.

Yeah, we've been in contact with a few KDE developers/maintainers. So far
the feedback has been positive so I think we're good on that front.

Cheers,
  Peter


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Peter Hutterer]

On Sun, Dec 28, 2014 at 09:42:07PM +0100, Alec Leamas wrote:
 On 28/12/14 18:05, Michael Catanzaro wrote:
 On Sun, Dec 28, 2014 at 9:48 AM, Alec Leamas leamas.a...@gmail.com wrote:
 Possibly. But isn't there quite a difference between the novice user
 and the Fedora Workstation target user i. e., developers?
 
 Not necessarily. I wrote:
 
 Yes, Workstation targets developers, but not exclusively, and also
 developers who use fancy IDEs and who don't work with the terminal. I
 just don't want this thread to degenerate into a discussion of this
 lousy definition [of normal/novice users], since it's not important.
 What's important is that we want Workstation to be excellent for users
 who never touch the terminal.
 
 
 Hm... developers which never touches the terminal?! Seems like a really
 narrow group (?)

it's not as narrow as you may think, developers may use the terminal
selectively for some tasks and the GUI exclusively for others. That subset
isn't the same for all developers, so you end up having to provide all
features working well in the GUI.

e.g. I hardly ever use nautilus to handle fils, but I also hardly ever use
the terminal for any configuration, connecting to networks, firewall stuff,
etc. etc. I hardly ever use it to start non-terminal apps except for
eog/evince.

so even though I use the terminal heavily, I still would count myself in the
above group and I definitely need a good GUI around my terminals. And,
I want my desktop to be simple and get out of the way of what I actually
want to do.

Cheers,
   Peter

 Fedora currently suffers from the impression that it is a complicated OS
 for advanced users only, and that novices (including novice developers)
 should use Ubuntu instead.
 
 I have full sympathy for this goal. Question is if it aligns with the
 developer target for the workstation?

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Change xorg input stack to use libinput

[Peter Hutterer]

On Sat, Dec 13, 2014 at 10:15:41AM +, Tom Hughes wrote:
 On 13/12/14 01:10, Kevin Kofler wrote:
 
 An additional objection I have to this change proposal is that libinput
 (deliberately) only implements a small subset of the configurability of the
 old drivers, and thus, if we are going to remove the old drivers entirely,
 we are taking away flexibility from our users.
 
 Indeed. Is it, for example, still the case that the libinput developers are
 refusing to consider things like definable button areas on clickpads so you
 can create a proper middle button?

Have you filed a bug for it?

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Change xorg input stack to use

[Peter Hutterer]

On Fri, Dec 12, 2014 at 03:38:04PM +0100, Rave it wrote:
 Am Fri, 12 Dec 2014 12:00:07 +
 schrieb devel-announce-requ...@lists.fedoraproject.org:
 
  Message: 1
  Date: Thu, 11 Dec 2014 14:42:11 +0100
  From: Jaroslav Reznik jrez...@redhat.com
  To: devel-annou...@lists.fedoraproject.org
  Subject: F22 System Wide Change: Change xorg input stack to use
  libinput
  Message-ID: 4092034.fsnsvv0...@dhcp-0-163.brq.redhat.com
  Content-Type: text/plain; charset=us-ascii
  
  = Proposed System Wide Change: Change xorg input stack to use libinput =
  https://fedoraproject.org/wiki/Changes/LibinputForXorg
  
  Change owner(s): Hans de Goede hdego...@redhat.com
  
  Replace the current (low-level) input xorg drivers with libinput using the 
  xorg-x11-drv-libinput wrapper. 
  
  == Detailed Description ==
  Currently xorg uses different input drivers depending on the device type. 
  This 
  makes it impossible to do things like middle button scrolling on the 
  trackpoint on laptops where the trackpoint buttons are software-emulated 
  buttons on the touchpad. Besides this the xf86-input-synaptics driver was 
  never really designed for multi-touch touchpads and this causes various 
  issues.
  
  For Wayland we've been working on a new improved input stack, which is to 
  be 
  shared by all compositors and lives inside libinput. We plan to replace the 
  current (low-level) input xorg drivers with libinput using the xorg-x11-drv-
  libinput wrapper. 
  
  == Scope ==
  Besides xorg changes, this will also require changes to the control panel 
  applets for mouse / touchpad configuration in the various desktop 
  environments, 
  as those all are hardcoded to use the xorg-x11-drv-synaptics specific 
  interfaces.
  
  * Proposal owners:
  Package libinput and xorg-drv-input-libinput (done), make sure that 
  xorg-drv-
  input-libinput has the necessary config interfaces for control panel 
  mouse/touchpad config applets (wip). Write patches for gnome-control-center 
  mouse/touchpad capplet. Coordinate with other desktop environments.
  
  * Other developers:
  GNOME: merge the gnome-control-center patches. KDE: limits itself to 
  standard 
  X11 mouse config interfaces, no changes needed. Other Desktop Environments: 
  adjust control-panel code to deal with xorg-x11-drv-libinput, merge these 
  changes.
  
  * Release engineering: N/A
  * Policies and guidelines: N/A
 
 I would be very helpful if you could target a x-server version when
 control-center apps should be ready for this change, to help upstreams.
 Can we expect that those x-server changes also land in other distro later?
 Or is this limited to fedora only?

The X server version is independent of this change. You can install
and use xorg-x11-drv-libinput right now and while I haven't tested it, the
driver probably works with anything newer than F18 or so.

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Change xorg input stack to use libinput

[Peter Hutterer]

On Sat, Dec 13, 2014 at 02:10:18AM +0100, Kevin Kofler wrote:
 Jaroslav Reznik posted (and
  Change owner(s): Hans de Goede hdego...@redhat.com
 wrote):
 
  KDE: limits itself to standard X11 mouse config interfaces, no changes
  needed.
 
 Not true. We ship kcm_touchpad on the KDE spin, which definitely does depend
 on synaptics interfaces (search for synaptics in:
 https://projects.kde.org/projects/playground/utils/kcm-touchpad/repository/revisions/master/entry/src/backends/x11/xlibbackend.cpp
  ).
 Anything that does not use the synaptics driver is not considered a
 touchpad. And kcm_touchpad is also in the process of becoming a core part of
 upstream Plasma. (It is currently in the git.kde.org playground.)
 
 Therefore, porting kcm_touchpad (the rewritten 1.x series we currently ship,
 not the old, obsolete, 0.3.x version, please make sure you look at the
 correct version) is an essential requirement before we can move away from
 the synaptics driver.
 
 
 An additional objection I have to this change proposal is that libinput
 (deliberately) only implements a small subset of the configurability of the
 old drivers, and thus, if we are going to remove the old drivers entirely,
 we are taking away flexibility from our users.

You are welcome to file bugs in the freedesktop.org bugzilla
(Wayland/libinput) for the feature requests you have. Some of them may be
closed as wontfix, but I suspect there are others the case isn't clear-cut.

Oh, and if you do so, don't just go through the synaptics/evdev man pages
and file a bug for every option in there. I want clear use-cases that
justify each features you want us to add.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Change xorg input stack to use libinput

[Peter Hutterer]

On Mon, Dec 15, 2014 at 10:38:50PM +, Tom Hughes wrote:
 On 15/12/14 21:39, Peter Hutterer wrote:
 On Sat, Dec 13, 2014 at 10:15:41AM +, Tom Hughes wrote:
 On 13/12/14 01:10, Kevin Kofler wrote:
 
 An additional objection I have to this change proposal is that libinput
 (deliberately) only implements a small subset of the configurability of the
 old drivers, and thus, if we are going to remove the old drivers entirely,
 we are taking away flexibility from our users.
 
 Indeed. Is it, for example, still the case that the libinput developers are
 refusing to consider things like definable button areas on clickpads so you
 can create a proper middle button?
 
 Have you filed a bug for it?
 
 Well based on 
 http://who-t.blogspot.co.uk/2014/09/libinput-common-input-stack-for-wayland.html
 I didn't think there was any point...

tbh, I'm not a fan of the feature at all, but then again a discussion may be
worth having. But I'm not going to have this discussion on this list here.

Please file a bug or bring it up on the wayland-devel list, then we can
weigh up the pros and cons there.

 What I did do after writing my email above was to go and half implement it,
 mostly to see if it would be feasible to maintain a locally patched
 libinput.
 
 So if you're interested I have code that (hopefully) allows a middle button
 to exist, but I haven't added any way of configuring that button yet so it's
 size is just hard coded.

fwiw, hardcoding the size is fine IMO. The detail is in the various corner
cases though, but if you already have it you're welcome to send it to the
wayland list (or attach it to the bug report).

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: How many users does Fedora have?

[Peter Hutterer]

On Mon, Dec 01, 2014 at 12:57:47PM +0100, Pierre-Yves Chibon wrote:
 On Mon, Dec 01, 2014 at 12:38:24PM +0100, Reindl Harald wrote:
  
  Am 01.12.2014 um 12:36 schrieb Alec Leamas:
  On 01/12/14 12:29, Reindl Harald wrote:
  
  Am 01.12.2014 um 12:26 schrieb Alec Leamas:
  
  Lets face it: I envy those who can measure the usage from a download
  counter or so. Can we have something similar?
  
  no - you have no clue which mirror was used without explicit tracking in
  YUM/DNF and given the noise about the recent Firefox changes you won't
  even consider seriously tracking inside the distribution
  
  additionally downloads are meaningless - many setups with more than one
  machine have their local mirrors and a download can be 1, 10 or 50
  installed instances
  
  I hesitated when writing my initial message, didn't include this:
  
  Feedback why this is impossible isn't really helpful here, most of us
  are aware of the limitations. Given that we agree on the overall goals
  (?), useful input is what can be done, and how
  
  it is helpful because the fact it is impossible will shutdown that
  discussion because - well, it's impossible
 
 The question becomes, is any numbers better than no number?
 
 In theory, we could get an idea of how much a package is downloaded. Mirror 
 are
 syncing all the content, so they introduce a baseline while user is what
 introduce the variability.
 So if we were to be able to gather logs from a) the main repos + b) some
 volunteer repos, we could get a trend.
 The number would of course not be exact as you mentioned but we could get an
 idea, something like: we have 132 mirrors and my package was downloaded 133
 times, which potentially means there is one user (me) using that package.
 There might be more, but if no-one ever reports a bug and we see the number of
 download is basically equal to the number of mirrors, we can get an impression
 that this package isn't used by many people.
 
 So we come back to the question: is any number better than no number at all?
 Even to get a trend?

it's the wrong question, because there is no one single answer. It depends
on what you want to _do_ with that number. Then you can decide how much
error is acceptable and work from there.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Sun, Nov 23, 2014 at 10:30:21AM +0100, Till Maas wrote:
 On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote:
  Hi, I am testing Fedora 21 beta and -like all previous versions- click
  by tapping is off by default.
  Several bug reports concerning this were closed as NOTABUG, but
  tapping is useful for us (people who use it), I don't think it bothers
  the others that much, and is on by default in most operating systems
  and Linux distributions.
 
 How about just asking the user once if several tap-to-click events are
 detected whether this should be enabled (and showing where to
 enable/disable it). Then if someone is trying to use it while it does
 not work, it can be easily enabled. And if someone does not want it but
 would accidently click, the message just needs to be ignored once.

not really possible in the current driver stack. Other than the synaptics
driver itself, there is no knowledge that an event was caused by a tap vs. a
physical button press. even the X server itself doesn't have that
information.

that is if tapping is enabled. if it is disabled, you don't get _any_ event
at all from tapping, the movement of the finger isn't sufficient to trigger
pointer movement and we don't expose the actual touch events to the clients.

Short of adding a custom protocol that desktop environments can talk to the
driver directly we're pretty much powerless here. And the idea of that
doesn't fill me with excitement, as I hope you can understand :)

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Sun, Nov 23, 2014 at 09:42:39AM +0100, Kevin Kofler wrote:
 Nikos Roussos wrote:
  It's a UX thing, so the Workstation WG seems like the best place to
  decide this (at least for Gnome).
 
 But the Workstation WG has no decision power over other desktop 
 environments, such as KDE, which, incidentally, is what the original poster 
 happens to use.
 
 And I insist, IMHO, desktop environments should not be overriding the 
 systemwide default here.

FTR, I disagree with this bit here. I think it's perfectly fine for a DE to
change the defaults to what it thinks is best for the out-of-the-box
experience.

Some things like tapping simply have no correct solution that works for
everyone and we have to pick one default. That doesn't mean that
everyone has to follow that default now.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Tue, Nov 18, 2014 at 09:16:34PM +0100, Jaroslav Nahorny wrote:
 
 Björn Persson bj...@xn--rombobjrn-67a.se writes:
 
  Jaroslav Nahorny jaros...@hackerspace.pl wrote:
  [1] I know it's a far analogy, but let's try to imagine:
  Let's disable wifi hardware by default. Why? Because some people are not
  aware of this feature. They want to use their eth interface, and having
  wireless interface turned on produces unnecessary „noise” and confusion.
  If somebody wants to use wifi, they can enable it.
  Seems legit, right?
 
  As far as I can tell Fedora doesn't automatically connect to Wifi
  networks it hasn't encountered before. You have to explicitly tell it
  to connect. Then, once you have enabled it, it may reconnect
  automatically thereafter. So yes, this seems not only legit; it seems
  to be reality.
 
 I didn't mean connecting (or not) to wireless networks, but disabling
 hardware from normal operation. This is what we are at the moment doing
 with touchpads. We are disabling a feature those devices have built-in.

you're aware that tapping is a pure software feature? if we didn't implement
it in the driver, it wouldn't exist.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Tue, Nov 18, 2014 at 10:05:01PM +0100, Kevin Kofler wrote:
 drago01 wrote:
 
  On Tue, Nov 18, 2014 at 6:50 AM, Mattias Ellert
  mattias.ell...@fysast.uu.se wrote:
 
  Even if you know that this weird feature exists, it will take you
  hours to disable it, since while you are trying to find your way through
  setting and control panels you will get tons and tons of random clicks
  that open random windows that needs to be closed and change random
  settings that you need to reset. And while you try to do this you get
  even more random clicks that open new windows and change other stuff.
  
  This has pretty much nothing to do with reality. So please write sane
  mails when you ask for sanity ;)
 
 It is when you have never used a tap-to-click device and thus are not used 
 to the extra-soft touch that it takes to move without tapping. Then 
 literally EVERY cursor move you make will trigger an accidental click. I 
 have personally experienced that. This is not an exaggeration at all.

that sounds like bug, please file it here:
https://bugs.freedesktop.org/enter_bug.cgi?product=xorg, component
Input/synaptics  with one or more evemu recordings attached that triggered
an accidental tap.

while tapping has its drawbacks, it's not supposed to be that bad.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Tue, Nov 18, 2014 at 10:59:24PM +0100, Jaroslav Nahorny wrote:
 
 Kevin Kofler kevin.kof...@chello.at writes:
 
  Erik Schilling wrote:
  Over the time I just got used to hitting the special button...
 
  And that's what that special button is for. :-)
 
  If the touchpad has physical buttons (or physically-drawn virtual 
  buttons), why do users even expect tapping to produce a click? The finger 
  area is for moving, the buttons are for clicking.
 
 For speed sake. You don't have to move your fingers. It's like with the
 scroll-wheel on a mouse. Why do you need a scroll wheel? You could as
 well just point the mouse to the scroll marker on right side of the
 window, click LMB and move the mouse. It's doable. Why do you need a
 scroll-wheel then. Or use PgUp / PgDown keys on your keyboard.
 
 Furthermore, why a mouse / touchpad at all? You can use keyboard for
 navigation.
 
 So those are personal preferences. One person prefers scroll-wheel, the
 other PgUp / PgDown keys. The thing is, a touchpad is a piece of
 hardware. With some features built-in. And we are by default disabling a
 feature this device offers out of the box.
 
 I know it's a matter of preferences. Exactly like the way you mount a
 roll of toilet paper on a wall
 (http://en.wikipedia.org/wiki/Toilet_paper_orientation). 

that page's existence just made my day. thanks :)
 
 I know some people hate this feature (tapping) and some love it. But I
 think, if the device have some capability (feature) it shouldn't be
 disabled by default.

slippery slope. synaptics has a lot of features that we don't enable by
default even though the hw has the theoretical capability. examples are
clickfinger, corner buttons, circular scrolling.

remember that a touchpad is just that, a surface that responds
to touch. everything else is done in the driver and there isn't really a
limit what you could do based on that capability. tapping is no more
built-in than pinch-to-zoom (which we don't even support atm).

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote:
 Hi, I am testing Fedora 21 beta and -like all previous versions- click
 by tapping is off by default.
 Several bug reports concerning this were closed as NOTABUG, but
 tapping is useful for us (people who use it), I don't think it bothers
 the others that much, and is on by default in most operating systems
 and Linux distributions.
 
 What can we do to make this happen?

This comes up every couple of versions, so here is the reasoning for
disabled by default:

* if you don't know that tapping is a thing (or enabled by default), you get
  spurious button events that make the desktop feel buggy.
* if you do know what tapping is and you want it, you usually know where to
  enable it, or at least you can search for it.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enable tapping by default

[Peter Hutterer]

On Tue, Nov 18, 2014 at 12:16:26AM +0200, Nikos Roussos wrote:
 On 11/18/2014 12:12 AM, Peter Hutterer wrote:
  On Mon, Nov 17, 2014 at 02:27:53PM +0300, Mustafa Muhammad wrote:
  Hi, I am testing Fedora 21 beta and -like all previous versions- click
  by tapping is off by default.
  Several bug reports concerning this were closed as NOTABUG, but
  tapping is useful for us (people who use it), I don't think it bothers
  the others that much, and is on by default in most operating systems
  and Linux distributions.
 
  What can we do to make this happen?
  
  This comes up every couple of versions, so here is the reasoning for
  disabled by default:
  
  * if you don't know that tapping is a thing (or enabled by default), you get
spurious button events that make the desktop feel buggy.
  * if you do know what tapping is and you want it, you usually know where to
enable it, or at least you can search for it.
 
 Well, in practice most users just think it's broken.

and you have references for most?

Cheers,
   Peter

 You forgot one case though.
 
 * If you know what tapping is and you don't want it (enabled by
 default), you know where to go to disable it.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Xorg crashes detected by ABRT

[Peter Hutterer]

On Thu, Oct 23, 2014 at 02:54:38AM -0400, Jakub Filak wrote:
 Hi folks,
 
 I ported the ABRT kernel oops detector to journald some time ago, because of
 NoDefaultSyslog change.
 
 I wanted to do the same with the ABRT Xorg stack trace detector (just because 
 I
 do not like the current implementation and it is possible now [2]), but
 I am not able to trigger the Xorg's stack trace dumper. I tried a couple of
 signals, but all my efforts led to a core dump file caught by the ABRT core
 dump hook.
 
 I thought I have the 'NoTrapSignals' option set to 'true', but 'grep
 NoTrapSignals -r /etc/ /usr/share/X11/' returns no results.
 
 Does Xorg handle the fatal signals on its own (it seems it does [3])?

yes, see OsSighandler() and OsInit(). 
http://cgit.freedesktop.org/xorg/xserver/tree/os/osinit.c
the signal handler calls xorg_backtrace() and eventually abort()

Cheers,
   Peter


 If so, how can I trigger it?
 
 Otherwise, I would love to remove the ABRT Xorg stack trace detector from
 Fedora.
 
 
 
 Regards,
 Jakub
 
 1: http://fedoraproject.org/wiki/Changes/NoDefaultSyslog
 2: http://who-t.blogspot.cz/2014/03/viewing-xorglog-with-journalctl.html
 3: https://bugzilla.redhat.com/show_bug.cgi?id=1035508#c1
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

libinput soname bump

[Peter Hutterer]

libinput 0.6 had a soname bump. I've rebuilt clutter, mutter, weston and
xorg-x11-drv-libinput already, there doesn't seem anything else that relies
on it.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Package review needed - xorg-x11-drv-libinput

[Peter Hutterer]

xorg-x11-drv-libinput is a libinput-based X driver. We hope that this one
will eventually replace synaptics, evdev, etc., so it's kinda a big thing :)

Anyone up for it?
https://bugzilla.redhat.com/show_bug.cgi?id=1113392

thanks!

Cheers,
   Peter

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

touchpad event data requested - palm detection

[Peter Hutterer]

We're currently working on a number of things to improve input devices in
libinput - the future input stack for wayland developers. What we need
is data to base our assumptions on, so I'm hereby asking the list to provide
some.

If you don't have a touchpad, please disregard this email.
If you're on RHEL or a derivative, F18 or older, please disregard this
demail.

One focus at the moment is palm detection. If you have a couple of minutes
to spare, please run the following command:

  $ sudo evemu-record /dev/input/event4  palm-data.txt

substitute event4 with the kernel device of your touchpad, running
evemu-record without arguments will give you a list.

While evemu is running, DO NOT use the touchpad. Use your laptop normally
otherwise (you can use a mouse where needed, only the touchpad events
are recorded).
Ideally, use your keyboard because what we're looking for are events
generated when you're not actually using the touchpad. Once completed,
ctrl+c evemu-record. Again, please DO NOT use the touchpad while the
recording is active or the data will be difficult/impossible to
analyse. You can re-run evemu-record if you don't think the data set is
good enough. Once you're done please go through the following steps:

Verify that the txt file contains data:
  $ grep -q ^E: palm-data.txt  echo all clear || echo no data
  If no data is available, please re-run evemu-record (see the F19/F20
  comment below though)

Record your kernel version and machine information:
  $ uname -r  device-info.txt
  $ cat /sys/class/dmi/id/modalias  device-info.txt

Create a tarball of the data:
  $ tar jcf palm-data.tar.bz2 palm-data.txt device-info.txt

Please use the output of this command for the subject line of your email:
  $ echo PALMDATA: `cat /sys/class/dmi/id/product_version`
  This helps identify data sets so we can have good coverage.
  Emails with a non-matching subject line will be deleted automatically.

Attach the tarball and send it to 
   libinputdatacollect...@gmail.com

Thanks in advance!

== Why do we need this? ==

While typing on a laptop keyboard, accidental contacts may happen on
the touchpad. This can create spurious movements or even tapping/clicking
events. To avoid it, we need software-detection for palms.

There are a lot of different touchpads out there with different capabilities
and sizes. Thus, events look different on those touchpads and we need to
figure out how to find common denominators to identify palms. The only way
to do this is to look at as many data sets as possible.

== A note on Fedora 19 and 20 ==

On Fedora 19 and Fedora 20, you will not see events on the touchpad device.
You need to restart X with the configuration snippet in place below:

$ cat /etc/X11/xorg.conf.d/99-synaptics-dontgrab.conf 
Section InputClass
Identifier synaptics don't grab
MatchDriver synaptics
Option GrabEventDevice off
EndSection

On F21+ this is the driver default (xorg-x11-drv-synaptics = 1.8) and the
snippet is not needed.

If you're on RHEL or a derivative, F18 or older, please disregard this
email.

== A note on security ==

evemu-record collects events only from the given device and records it in a
plain-text format. If you set it to your keyboard, all keys pressed will be
visible in the order they were pressed. This can leak passwords, so DO NOT
record your keyboard device! If you set it to your touchpad as requested, no
key events are recorded. You can verify the data collected by looking at the
output file. evemu-record does not send or receive data and requires you
actively emailing the data.

If you do not want to run evemu-record as root, simply chmod the event file
for reading.

== A note on privacy  ==

Events from your touchpad cannot usually personally identify you, and
neither can the kernel version nor the DMI data. This process is opt-in, you
need to actively email the data. 

Your email can personally identify you, but we won't use the email
addresses for anything. The data you send (i.e. the tarball) will be used
for analysis and will be made publicly available to others to do analysis.
At this point, only I have access to that gmail account but I may extend
this to others involved with libinput. If you feel uncomfortable with any of
this, simply don't participate.

Cheers,
   Peter



pgpWC0wlAWHid.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: making Ctrl-Alt-Bksp work

[Peter Hutterer]

On Thu, May 08, 2014 at 11:43:08PM -0400, Felix Miata wrote:
 On 2014-05-08 08:43 (GMT+1000) Peter Hutterer composed:
 
 On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:
 
 Your (locale pt) and Reindl's (locale de) answers beg two questions:
 
 1-why do 00-keyboard.conf for pt and de contain
 terminate:ctrl_alt_bksp, but for locale us it is absent?
 
 2-what creates 00-keyboard.conf in the first place, since it doesn't
 get automatically recreated even by rebooting if deleted?
 
 systemd-localed. This file is written when you change the locale, either
 during install or later with localectl. It doesn't automatically get
 restored when you delete it.
 
 http://fedoraproject.org/wiki/Input_device_configuration
 lists the magic command as:
 localectl set-x11-keymap us   terminate:ctrl_alt_bksp
 
 On a Rawhide system originally installed 6 weeks ago running in
 multi-user I deleted 00-keyboard.conf, then did yum upgrade, and
 before rebooting the new kernel tried that command, with these
 results:
 
 Failed to set keymap: Connection timed out
 new 00-keyboard.conf not written
 I had to force a reboot, as most anything I tried related to shutting down 
 timed out.

loginctl doesn't write the file, it talks over dbus to systemd-logind which
writes out the file. This is the connection that failed, for some reason.

 After reboot it succeeded, but I still wonder why CAD gets enabled
 there at installation time for pt and de by not us. :-(

what's in your /etc/vconsole.conf? We've now reached a point where it's
better to file a bug report though.

Cheers,
   Peter


 which communicates the new keymap to systemd-localed, which then writes out
 the file.
 
 but having just tested this on F20, just running localectl set-keymap us
 also writes out the right configuration, including the terminate option. The
 above is needed for custom x11 keymaps, but shouldn't be needed for normal
 setup.
 
 re 2: Maybe your two installations have 00-keyboard.conf carried
 over from before xorg-x11-drv-keyboard was superceded by
 xorg-x11-drv-evdev, which on (re)installation does not create it if
 it does not exist?
 
 neither the keyboard nor the evdev driver have anything to do with it. the
 retirement of the keyboard driver should have no effect on anything newer
 than, say, Fedora 12.
 
 Zapping in the server works as a two-stage process. A key combination is
 interpreted by a XKB as a Terminate_Server action. The server then
 interprets that and terminates. With DontZap you only control the
 second part, i.e. whether the server terminates when the action is triggered.
 If you don't have the XKB setting, you can't trigger it in the first place.
 And DontZap is only useful if you want to _prohibit_ zapping completely. It
 just makes Terminate_Server do nothing.
 
 For your use-case, forget about DontZap, it has no effect. I'm the
 maintainer for these parts of the server, so regardless of how many
 configurations you find that tell you to enable it, please trust my word
 here. You need to get the terminate XKB option into your keymap, that's all
 that matters.
 
 FWIW, on one F21 system with radeon video here even a normal exit
 from a startx KDE session is leaving the screen on the tty started
 from black. A shift to a tty and back then draws what had been
 expected. I've tried on 6+ other installations, one with radeon, and
 all the others behave as expected.
 -- 
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)
 
  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
 
 Felix Miata  ***  http://fm.no-ip.com/
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: first and only X needs to be on tty7

[Peter Hutterer]

On Tue, May 06, 2014 at 12:21:05AM -0400, Felix Miata wrote:
 On 2014-05-06 11:04 (GMT+1000) Peter Hutterer composed:
 
 On Mon, May 05, 2014 at 11:45:31AM -0400, Felix Miata wrote:
 
 I might not even care about the location of X sessions if only it
 wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS
 not work any more?
 
 http://who-t.blogspot.com.au/2009/04/zapping-server.html
 
 Are you by providing that link in any way suggesting that there's
 been a keymap change that needs a user adjustment (for KDE users
 anyway if not others)? It provides no help where to look to make it
 happen globally in a post-sysvinit world.

there is no globally and it has nothing to do with being post-sysvinit.
you can add it to the default options on startup with an InputClass section
(which we do, check /etc/X11/xorg.conf.d/00-keyboard.conf) so it'll work out
of the box until something overwrites the user's keymap. That something
could be gdm or your desktop environment, ymmv.

if you want it set for your user in GNOME, install gnome-tweak-tool, it's in
Typing, iirc. Other desktops have other ways to configure it, but I don't
know those off-heart.
 
 For years, probably since the time of that document, I've had
 
   Option  DontZap   off
   Option  ZapWarningoff
 
 somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but

DontZap disallows zapping completely, regardless of your xkb settings. But
you're setting it to what is the default, so it has no effect. ZapWarning
is not an option in Fedora, it's an old SuSE patch that never got merged
upstream. Your config has no effect since X server 1.6 or possibly longer.

 only in Fedora (at least as far back as F14, worked as recent at
 least as F8), so far that I've noticed.

F11 had this change, judging by the package names I linked to in that blog
post.
 
 They still get the job done in Cauldron's 1.15.99.902, Factory's
 1.15.99.902.2 and Linux Mint LMDE (aka Debian Jessie/Sid) 1.14.3.

yeah, and Fedora stays close to upstream, so we don't have those patches.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: making Ctrl-Alt-Bksp work (was: first and only X needs to be on tty7)

[Peter Hutterer]

On Tue, May 06, 2014 at 06:15:12AM -0400, Felix Miata wrote:
 On 2014-05-06 00:13 (GMT-0700) Samuel Sieb composed:
 
 Felix Miata wrote:
 
 For years, probably since the time of that document, I've had
 
  OptionDontZapoff
  OptionZapWarningoff
 
 somewhere in /etc/X11/xorg.con*. It used to work. Now it fails, but only
 in Fedora (at least as far back as F14, worked as recent at least as
 F8), so far that I've noticed.
 
 I use the following that works on F20:
 # cat /etc/X11/xorg.conf.d/99-zap.conf
 Section ServerFlags
   Option DontZap false
 EndSection
 
 Section InputClass
   Identifier  Keyboard Defaults
   MatchIsKeyboard yes
   Option  XkbOptions terminate:ctrl_alt_bksp
 EndSection

fwiw (only answering one email) this is what systemd-localed should drop
into /etc/X11/xorg.conf.d/00-keyboard.conf, with configuration based on
whatever language settings you picked. so you shouldn't need this section.

 Thank you!
 
 Turns out DontZap works with either false or off, but the difference

the option parser in X is entertaining. no, off, false, and 0 all
work to disable, and so does prefixing the option with No. So Option
NoDontZap off is valid, just don't expect anyone to understand a
triple-negation :) you can also sprinkle random whitespaces or underscores
in there, in case you have too many of them.

Cheers,
   Peter

 between SUSE and Fedora is the addtional need for XkbOptions in
 Fedora, and here's why:
 
 /usr/share/X11/xkb/rules/
 --- evdev 2014-01-29 22:45:32.0 -0500
 +++ evdev-suse2014-04-09 15:51:53.0 -0400
 @@ -857,9 +857,9 @@
*  yu  unicodeyz   =   +srp(latinunicodeyz):4
 
  ! model  =   symbols
 -  $evdevkbds=   +inet(evdev)+inet(%m)
 -  applealu_jis  =   +inet(evdev)+macintosh_vndr/jp(alujiskeys)
 -  * =   +inet(evdev)
 +  $evdevkbds=   +inet(evdev)+inet(%m)+terminate(ctrl_alt_bksp)
 +  applealu_jis  =   
 +inet(evdev)+macintosh_vndr/jp(alujiskeys)+terminate(ctrl_alt_bksp)
 +  * =   +inet(evdev)+terminate(ctrl_alt_bksp)
 
  ! model  layout  =   symbols
 
 Using the SUSE evdev file in place of Fedora's my original xorg.con*
 that used to work also in Fedora works in it again without need for
 the XkbOptions addition.
 -- 
 The wise are known for their understanding, and pleasant
 words are persuasive. Proverbs 16:21 (New Living Translation)
 
  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
 
 Felix Miata  ***  http://fm.no-ip.com/
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: making Ctrl-Alt-Bksp work

[Peter Hutterer]

On Wed, May 07, 2014 at 02:38:59PM -0400, Felix Miata wrote:
 On 2014-05-07 19:03 (GMT+0100) Sérgio Basto composed:
 
 yes Ctrl-Alt-Bksp works and restart X , as Reindl Harald notice, I also have
 
 Option XkbOptions terminate:ctrl_alt_bksp,
 
 cat /etc/X11/xorg.conf.d/00-keyboard.conf
 
  Option  XkbModel  pc105
  Option  XkbLayout pt
  Option  XkbOptionsterminate:ctrl_alt_bksp,
 
 my video card is :
 [52.601] (II) intel(0): [DRI2]   DRI driver: i965
 
 DontZoom don't works , you are right
 
 Your (locale pt) and Reindl's (locale de) answers beg two questions:
 
 1-why do 00-keyboard.conf for pt and de contain
 terminate:ctrl_alt_bksp, but for locale us it is absent?
 
 2-what creates 00-keyboard.conf in the first place, since it doesn't
 get automatically recreated even by rebooting if deleted?

systemd-localed. This file is written when you change the locale, either
during install or later with localectl. It doesn't automatically get
restored when you delete it.

http://fedoraproject.org/wiki/Input_device_configuration
lists the magic command as:
   localectl set-x11-keymap us   terminate:ctrl_alt_bksp

which communicates the new keymap to systemd-localed, which then writes out
the file.

but having just tested this on F20, just running localectl set-keymap us
also writes out the right configuration, including the terminate option. The
above is needed for custom x11 keymaps, but shouldn't be needed for normal
setup.

 re 2: Maybe your two installations have 00-keyboard.conf carried
 over from before xorg-x11-drv-keyboard was superceded by
 xorg-x11-drv-evdev, which on (re)installation does not create it if
 it does not exist?

neither the keyboard nor the evdev driver have anything to do with it. the
retirement of the keyboard driver should have no effect on anything newer
than, say, Fedora 12.

Zapping in the server works as a two-stage process. A key combination is
interpreted by a XKB as a Terminate_Server action. The server then
interprets that and terminates. With DontZap you only control the
second part, i.e. whether the server terminates when the action is triggered.
If you don't have the XKB setting, you can't trigger it in the first place.
And DontZap is only useful if you want to _prohibit_ zapping completely. It
just makes Terminate_Server do nothing.

For your use-case, forget about DontZap, it has no effect. I'm the
maintainer for these parts of the server, so regardless of how many
configurations you find that tell you to enable it, please trust my word
here. You need to get the terminate XKB option into your keymap, that's all
that matters.

Cheers,
   Peter
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: first and only X needs to be on tty7

[Peter Hutterer]

On Mon, May 05, 2014 at 11:45:31AM -0400, Felix Miata wrote:
 I might not even care about the location of X sessions if only it
 wasn't so complicated to kill a broken one. Why doesn't Ctrl-Alt-BS
 not work any more?

http://who-t.blogspot.com.au/2009/04/zapping-server.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct