Re: [opensuse-gnome] Running Xorg non-root
Bjørn Lie writes:
ti., 12.01.2016 kl. 19.29 +0100, skrev Egbert Eich:
We could add a 'recommends:' or 'suggests:' to the affected driver packages. Since these packages are only installed if the hardware is found, the user will not get the wrapper normally.
I'd have no issues with this. But lets start with a suggests please :-)
The problem with suggests: is that IHMO we have nothing that honors them. There is no tool that tells you: oh, btw, here are packages that we suggest should be installed as well. Recommends have this weird 'take all or nothing' setting.
> > This will hopefully "encourage" upstreams to port their drivers, or > switch to other ones.
This will not happen. Most of the hardware supported by the UMS drivers is of marginal relevance today. Therefore the drivers are not really supported. Upstream just makes sure they still build. Some community users (openSUSE) complain if they don't work as expected in which case I often reply, that it is a free software project where everybody can contribute - if someone is interested in such hardware (s)he should expect to have to fix issues her/himself.
Right, then I have no problem just ignoring those users, as in: We are sorry, but you will have to use something else than GNOME for this hardware. Gnome does not support it anymore.
Sure, I'm fine with doing this for users who complain about actual bugs. I would like to accomodate those who simply want to use a still working driver at least to some extent. You cannot seriously expect that one of the people already working hard on supporting the current drivers to port S3, Trident, Matrox, SiS or VIA to KMS.
> > > > Input: > > ======
Yeah, you can. Just not configure them from Gnome.
Oh have you tested? - that commit is only 8 days old and we do not have it in GNOME:Next yet.
I have not tested, but these drivers will work in X.Org at least. So as long as Gnome supports Xorg, they will continue to work. You will have to do the setup using 'xinput' though.
If the hardware still works, I suppose this is the best we have to offer (at least in openSUSE). From upstream bug, it's being suggested that this commit can be reverted for those who want/have to, but I'd prefer not to deviate. - I see how you might have different needs in SLE though.
We cannot use this on SLE. At least not SLE-12. It is still too bleeding edge. At least for SP2.
Yeah, possibly. I'm not even sure - have we done this on TW already? Last time I've checked we hadn't. IHMO we should do this there ASAP to have a good test coverage.
Great news :-) as my SR to enable automatic install of xf86-input- libinput a month ago was nacked. I can probably fire up a new one some time tomorrow. We did have it as autoinstalled back in March, but at the time, neither the driver nor DE's were properly ready for it. Should be quite a different story today (I've been using it on all my boxes since summer).
I'm not yet sure how to deal with this on Tumbleweed. On one side I would like to have this as a test bed for bleeding edge things, on the other hand I would not want to enforce everything new on everybody. Point is: you may want to try out new things in one area to catch issues, but in other areas you would like to stay more conservative. If you have too fight too many fires because everything is bleeding edge, you may lose interest. I need to think about this some more and certainly discussing this also helps. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit :
ti., 12.01.2016 kl. 19.29 +0100, skrev Egbert Eich:
We could add a 'recommends:' or 'suggests:' to the affected
driver
packages. Since these packages are only installed if the hardware is found, the user will not get the wrapper normally.
I'd have no issues with this. But lets start with a suggests
Bjørn Lie writes: please :-)
The problem with suggests: is that IHMO we have nothing that honors them. There is no tool that tells you: oh, btw, here are packages that we suggest should be installed as well. Recommends have this weird 'take all or nothing' setting.
Why not use a Requires for those drivers, on the suid wrapper.
Input: ======
Yeah, you can. Just not configure them from Gnome.
Oh have you tested? - that commit is only 8 days old and we do not
have
it in GNOME:Next yet.
I have not tested, but these drivers will work in X.Org at least. So as long as Gnome supports Xorg, they will continue to work. You will have to do the setup using 'xinput' though.
For what it worth, I've been using the xf86-input-libinput on Leap 42.1 for several weeks now and it is working great (setup is a trackball, a integrated touchpad on Dell laptop and an external touchpad from Logitech, which can do multi-touch..).
If the hardware still works, I suppose this is the best we have to offer (at least in openSUSE). From upstream bug, it's being suggested that this commit can be reverted for those who want/have to, but I'd prefer not to deviate. - I see how you might have different needs in SLE though.
We cannot use this on SLE. At least not SLE-12. It is still too bleeding edge. At least for SP2.
I guess it will depend how much multitouch we want to support but those questions are out of topic for this mailing list ;)
Yeah, possibly. I'm not even sure - have we done this on TW
already?
Last time I've checked we hadn't. IHMO we should do this there ASAP to have a good test coverage.
Great news :-) as my SR to enable automatic install of xf86-input- libinput a month ago was nacked. I can probably fire up a new one some time tomorrow. We did have it as autoinstalled back in March, but at the time, neither the driver nor DE's were properly ready for it. Should be quite a different story today (I've been using it on all my boxes since summer).
I'm not yet sure how to deal with this on Tumbleweed. On one side I would like to have this as a test bed for bleeding edge things, on the other hand I would not want to enforce everything new on everybody. Point is: you may want to try out new things in one area to catch issues, but in other areas you would like to stay more conservative. If you have too fight too many fires because everything is bleeding edge, you may lose interest. I need to think about this some more and certainly discussing this also helps.
I guess we'll have do to the jump one day or another (IIRC, Fedora did the jump on their latest release). I would do a phased jump: - do a formal announcement (and even a blog post) on factory mailing list to ask people using TW to switch their setup to xf86-input -libinput and report behaviour changes and other bugs. - ask similar tests on Leap (maybe with some version bump of xf86-input -libinput and libinput package) - once dust settles, switch TW to xf86-input-libinput and wait for the next wave of bug reports and potentially retract the switch, fix stuff and switch back. - switch next Leap to it (and maybe a SLE SP) - world domination ;) -- Frederic Crozat Enterprise Desktop Release Manager SUSE -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org
participants (2)
-
Egbert Eich -
Frederic Crozat