Re: What is evdev and autoloading?

On Tue, 19 Feb 2019 06:25:32 -0800 (PST)
"Rodney W. Grimes" <freebsd-rwg_at_pdx.rh.CN85.dnsmgr.net> wrote:

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

 I'm pretty sure that you can find more user of -CURRENT that are happy
that i915kms from base isn't loaded automatically than users who aren't.

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

 No, it's easier for amd64 users (which should not use the legacy-drm
anyway) but harder (apparently) for i386 users, which are what ? 1% of
our base users ? (at least for graphics purpose)
 And no I'm not saying that we should left them alone, but clearly the
graphics team don't have the resources (time or people) do deal with
all the arches. We are now two people working on drm for arm/arm64 and
we hope to have something commitable soon, we need the same thing for
i386 (and probably other arches).

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

 Again wrong, this is a big leap forward for 99% of the 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
> _______________________________________________
> freebsd-hackers_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe_at_freebsd.org"

 Cheers,

-- 
Emmanuel Vadot <manu_at_bidouilliste.com> <manu_at_freebsd.org>