Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit : > 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.
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: [email protected] To contact the owner, e-mail: [email protected]
