Frederic Crozat writes:

Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit :

...

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.

This was my plan. I hope we will have the Recommends:/Suggests: mess resolved soon so that we have tools where users can actually view and (de)select them.

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..).

I bet it does for you and will do for Stefan, Michal and me as well. All of us have a pretty standard setup. We are not using a touchscreen or any wacom device ;p

...

...

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 ;)

Right. Hint: there is no 'one thing makes everybody happy'. We may have to offer two solutions.

...

...

...

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).

Yes, but the developers of most of this are working for RH and RH has simplified things by dropping support for a lot of things altogether which we still support. They never had an fbdev fallback mode AFAIK.

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.

Please make it a special program: tell people what to do to participate in this test endeavor and how to get back if it doesn't work at all.

- ask similar tests on Leap (maybe with some version bump of xf86-input -libinput and libinput package)

Please don't do this on Leap! People there may have a different expectation set. Let's not blur the distinction between Leap and Tumbleweed!

- 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.

I'd rather switch the default once: give people the option to switch before already or switch back after: personal choice - depending on needs.

- switch next Leap to it (and maybe a SLE SP)

If things look good, why not? Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-gnome+owner@opensuse.org