Re: What is evdev and autoloading?

> > On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko <gonzo_at_bluezbox.com> wrote:
> > 
> > Michael Gmelin (grembo_at_freebsd.org) wrote:
> >> 
> >> 
> >>>> On 18. Feb 2019, at 23:54, Mark Linimon <linimon_at_lonesome.com> wrote:
> >>>> 
> >>>> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
> >>>> I think one serious problem here is the summary dismissal of things
> >>>> simply on the "5 year old" basis.
> >>> 
> >>> IIUC the graphics changes are being forced upon FreeBSD by external
> >>> projects (mainly Linux-based) that are making huge architectural changes
> >>> that rely more and more on features from newer hardware.

The port was created long ago to get newer graphcis, that port even
had very nice instructions on how to bypass the inbase kmod of the
same name that accsesed the same hardware.

> >>> 
> >>> If our upstreams aren't willing to do the work to keep from violating
> >>> POLA on older hardware, IMHO it's an awful lot to ask of our already
> >>> thinly stretched graphics volunteers to provide it in their stead.
> >>> 
> >>> w/rt graphics, we are at far more danger of being left further and
> >>> further behind on modern hardware than we are at risk of losing users
> >>> on older hardware here.

We had the kmod in ports that supported this, no one was being
left behind in any respect of the word.  We are certainly driving
users away by our operation model, I here it often from several
different places I interact with users, linux conferences, oscon,
local user group meetings, other BSD users that have moved to
another platform, our own #freebsd irc channel.

> >>> 
> >>> Again all IMHO.
> >>> 
> >>> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> >>> say around here)
> >> 
> >> I?m very happy (and grateful) that 2018 was the first year in over a decade I was able to run FreeBSD on a state of the art laptop with all the features that are essential to me working - which included decent touchpad support provided through evdev+libinput.
> > 
> > I want to second this. evdev + libinput was the only option out of
> > several that provided smooth multitouch experience for Xorg on my 2018
> > laptop I really appreciate all the efforts to make it work both on
> > kernel and ports side.
> > 
> > -- 
> > gonzo
> 
> If I may throw my 0,02?, getting a newer graphics stack also gives me (and others) the option to combine many machine functions into one; for example, I can use a single machine as all the usual things like: router+firewall(ipfw), fileserver which can satuate 1Gbps LAN and WAN with NFSv4 and/or SMB, and many other things (those aren?t _that_ new)
> What is new is that we can now use it as a media center for efficient hardware accelerated playback of h264 and h265, as well as on-the-fly transcoding to stream to mobile devices via libva or vdpau, qsv or similar.

The new driver exists and existsted before any touching of in base DRM2
happened.  Many seem to be ignoring that fact, you did not get any new
software, you simply moved the bits around a little.

And the root problem, not being able to easily over ride an inbase
module with a module for ports is only slighly better addressed
in that we can now blacklist modules (that is a net gain, but from
looking at things that is the only gain here.)

Let me repeat, there is no new supported hardware or software that
did not exist before the removal of in base DRM2, and it is only
very slightly easier to use the new drm2 kmod for new hardware,
and slighly more difficult to use the legacy drm2 kmod moved
to ports.

This is not some leap forward for anyone, and defanitly a slight
step backwards for some, many, who knows, I put it in the 1000's,
of users.

We have never been very good at having kmod's
work well over a long period, we break them left and right, and
we got away with it in virtualbox, but you start doing that to
the graphics driver and you are going to driver users away as
they simply can not have there desktop go non-functional for
even hours, let alone days.

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org