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(a)opensuse.org
To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org
