Re: What is evdev and autoloading?
W dniu 18.02.2019 o 18:17, Pete Wright pisze: > > > On 2/18/19 8:50 AM, Rodney W. Grimes wrote: >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >>> >>> I don't know. I think the fact that drm2 doesn't support anything newer >>> than 5-year-old hardware is a pretty convincing evidence that the >>> old way >>> is broken and doesn't work. >> But it DOES work, I am pretty sure we have 1000's of users on that 5 >> year >> old hardware that are totally happy with the intree DRM2 that is in >> stable/12, >> and some of whom have ventured into head/13 are having issues with >> thete a >> "new" model (ie kmod broken by a base commit). I know that there is wip >> to get CI coverage for that, but wip is wip, and we need to start >> changing >> the cart horse driver order we keep doing and get things right. Port >> up and working, with CI testing *before* we go remove kmod'ed code from >> base would be a much more appropriate path. >> >> I think one serious problem here is the summary dismissal of things >> simply on the "5 year old" basis. Not everyone, and infact few now >> a days other than corporate buyers, can afford new hardware, >> giving the minimal performance increase in systems over the last 5 >> years the cost/benifit factor of a new computer is just too low. > I've put a lot of effort helping test and document how to get a usable > desktop environment on a modern laptop. there were two issues which > motivated me to do this: > > 1) my observation that many developers at conferences and online were > using macOS as their primary desktop environment. when comparing this > to the OpenBSD and Linux community I felt pretty embarrassed, but it > did explain the stagnant nature of our graphics subsystem. people > seemed afraid to touch things due the brittle nature of its hardware > support. > > 2) i was in need to an *affordable* machine with a warranty. > fortunately there are many affordable laptops at staples, best-buy and > amazon - but they were all post haswell systems, rendering them > basically useless from a FreeBSD perspective. > > after trying to get traction to update the in-tree drm subsystem i was > lucky enough to sync up with the graphics team which was working on > syncing things up with modern hardware support. because of that i'm > now able to get my small startup pretty much all on board with > FreeBSD. i use it on my workstations as well as on or server > infrastructure (physical and AWS). i would consider this a success > for our community as it's opened up the eyes to a whole new generation > of devs to FreeBSD. > > one thing missing from all of these arguments is real data. how many > people are on haswell era hardware? i can tell from my experience the > past several years the number of people who have post-haswell gear > seem to be more numerous, or at least more vocal (and frankly easier > to work with while squashing bugs). > > i can also say that personally it would be great to improve support > for systems requiring drm2 - but that gear is hard to come by, so we > are really dependent on helpful collaboration from those who are being > effected. > Thank you for reworking laptop hardware support, it has been improved a lot lately. Nowadays almost everything works out of the box. In my case things not working, for a brand new laptop, had patches in the review and available to download from FreeBSD Phabricator. Laptop support is the key to gain popularity of the OS, especially among the younger generation of users. From the other hand, I am not able to boot 12.0 RELEASE on a couple of ~10 years old servers, though I still can actively follow 11-STABLE there. It's not easy to find the cause of the breakage. I'd like to encourage you Developers to MFC as much as we can handle into the STABLE branch to involve even more users into the software testing process. Breaking ABI is unacceptable, but brave MFC would sometimes help the community avoid/reduce a gap between STABLE and CURRENT which accumulates and appears in the final of the release cycle. With best regards, -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: What is evdev and autoloading?
On Tue, 19 Feb 2019 11:18:07 -0800 Steve Kargl wrote: > On Tue, Feb 19, 2019 at 06:59:26PM +, Johannes Lundberg wrote: >> On 2/19/19 5:35 PM, Steve Kargl wrote: >>> My Dell Latitude D530 running i386 freebsd, which used the >>> i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs >>> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. >>> It seems that Niclas has provided a patch that fixes the building >>> of drm-legacy-kmod. >>> >>> Doing a bisection on /usr/src commits is fairly slow as it >>> takes a day to build world/kernel and the minimum set of ports >>> need to fire up Xorg. r343543 and earlier appear to work fine >>> with drm-legacy-kmod. >> >> So it's not only a build error, it's also a runtime bug that would have >> happened even with drm2 in base? Hmm.. > > It appears that that's the case. The likely candidates > are r343564(+65 for missing header), r343566, and r343567. That last commit added hw.above4g_allow tunable. Does it help if you set this to 0 in /boot/loader.conf? Also, it's worth trying drm-current-kmod if you haven't done so recently. If you did try already what were the problems? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On February 19, 2019 9:35:54 AM PST, Steve Kargl wrote: >On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote: >> On February 18, 2019 9:17:37 AM PST, Pete Wright > wrote: >> > >> > >> >On 2/18/19 8:50 AM, Rodney W. Grimes wrote: >> >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >> >>> >> >>> I don't know. I think the fact that drm2 doesn't support anything >> >newer >> >>> than 5-year-old hardware is a pretty convincing evidence that the >> >old way >> >>> is broken and doesn't work. >> >> But it DOES work, I am pretty sure we have 1000's of users on that >5 >> >year >> >> old hardware that are totally happy with the intree DRM2 that is >in >> >stable/12, >> >> and some of whom have ventured into head/13 are having issues with >> >thete a >> >> "new" model (ie kmod broken by a base commit). I know that there >is >> >wip >> >> to get CI coverage for that, but wip is wip, and we need to start >> >changing >> >> the cart horse driver order we keep doing and get things right. >Port >> >> up and working, with CI testing *before* we go remove kmod'ed code >> >from >> >> base would be a much more appropriate path. >> >> >> >> I think one serious problem here is the summary dismissal of >things >> >> simply on the "5 year old" basis. Not everyone, and infact few >now >> >> a days other than corporate buyers, can afford new hardware, >> >> giving the minimal performance increase in systems over the last 5 >> >> years the cost/benifit factor of a new computer is just too low. >> >I've put a lot of effort helping test and document how to get a >usable >> >desktop environment on a modern laptop. there were two issues which > >> >motivated me to do this: >> > >> >1) my observation that many developers at conferences and online >were >> >using macOS as their primary desktop environment. when comparing >this >> >to the OpenBSD and Linux community I felt pretty embarrassed, but it >> >did >> >explain the stagnant nature of our graphics subsystem. people >seemed >> >afraid to touch things due the brittle nature of its hardware >support. >> >> I noticed this too. And every time it struck me as odd. >> >> > >> >2) i was in need to an *affordable* machine with a warranty. >> >fortunately >> >there are many affordable laptops at staples, best-buy and amazon - >but >> > >> >they were all post haswell systems, rendering them basically useless > >> >from a FreeBSD perspective. >> >> Which is why removing drm2 was necessary. >> >> > >> >after trying to get traction to update the in-tree drm subsystem i >was >> >lucky enough to sync up with the graphics team which was working on >> >syncing things up with modern hardware support. because of that i'm >> >now >> >able to get my small startup pretty much all on board with FreeBSD. >i >> >use it on my workstations as well as on or server infrastructure >> >(physical and AWS). i would consider this a success for our >community >> >as it's opened up the eyes to a whole new generation of devs to >> >FreeBSD. >> > >> >one thing missing from all of these arguments is real data. how >many >> >people are on haswell era hardware? i can tell from my experience >the >> >past several years the number of people who have post-haswell gear >seem >> > >> >to be more numerous, or at least more vocal (and frankly easier to >work >> > >> >with while squashing bugs). >> > >> >i can also say that personally it would be great to improve support >for >> > >> >systems requiring drm2 - but that gear is hard to come by, so we are > >> >really dependent on helpful collaboration from those who are being >> >effected. >> >> Drm2 is not required. My current laptop is 5 years old, an HD3000. >The previous one is 13 years old, i915. Both work perfectly with >drm-current on 13-current. Franky, I don't see what the fuss is about. >> >> > >My Dell Latitude D530 running i386 freebsd, which used the >i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs >non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. >It seems that Niclas has provided a patch that fixes the building >of drm-legacy-kmod. > >Doing a bisection on /usr/src commits is fairly slow as it >takes a day to build world/kernel and the minimum set of ports >need to fire up Xorg. r343543 and earlier appear to work fine >with drm-legacy-kmod. > >I have now lost 2 weeks of hacking time that could have been spent >on the missing C99 complex math routines. Yeah, I know very few >people care about numerical simulations on FreeBSD. Going down an unexpected rabbit hole is frustrating. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Tue, Feb 19, 2019 at 06:59:26PM +, Johannes Lundberg wrote: > > On 2/19/19 5:35 PM, Steve Kargl wrote: >> On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote: >>> >>> Drm2 is not required. My current laptop is 5 years old, an HD3000. The >>> previous one is 13 years old, i915. Both work perfectly with drm-current on >>> 13-current. Franky, I don't see what the fuss is about. >>> >>> >> My Dell Latitude D530 running i386 freebsd, which used the >> i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs >> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. >> It seems that Niclas has provided a patch that fixes the building >> of drm-legacy-kmod. >> >> Doing a bisection on /usr/src commits is fairly slow as it >> takes a day to build world/kernel and the minimum set of ports >> need to fire up Xorg. r343543 and earlier appear to work fine >> with drm-legacy-kmod. > > So it's not only a build error, it's also a runtime bug that would have > happened even with drm2 in base? Hmm.. It appears that that's the case. The likely candidates are r343564(+65 for missing header), r343566, and r343567. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/19/19 5:35 PM, Steve Kargl wrote: > On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote: >> On February 18, 2019 9:17:37 AM PST, Pete Wright wrote: >>> >>> On 2/18/19 8:50 AM, Rodney W. Grimes wrote: > On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < > > I don't know. I think the fact that drm2 doesn't support anything >>> newer > than 5-year-old hardware is a pretty convincing evidence that the >>> old way > is broken and doesn't work. But it DOES work, I am pretty sure we have 1000's of users on that 5 >>> year old hardware that are totally happy with the intree DRM2 that is in >>> stable/12, and some of whom have ventured into head/13 are having issues with >>> thete a "new" model (ie kmod broken by a base commit). I know that there is >>> wip to get CI coverage for that, but wip is wip, and we need to start >>> changing the cart horse driver order we keep doing and get things right. Port up and working, with CI testing *before* we go remove kmod'ed code >>> from base would be a much more appropriate path. I think one serious problem here is the summary dismissal of things simply on the "5 year old" basis. Not everyone, and infact few now a days other than corporate buyers, can afford new hardware, giving the minimal performance increase in systems over the last 5 years the cost/benifit factor of a new computer is just too low. >>> I've put a lot of effort helping test and document how to get a usable >>> desktop environment on a modern laptop. there were two issues which >>> motivated me to do this: >>> >>> 1) my observation that many developers at conferences and online were >>> using macOS as their primary desktop environment. when comparing this >>> to the OpenBSD and Linux community I felt pretty embarrassed, but it >>> did >>> explain the stagnant nature of our graphics subsystem. people seemed >>> afraid to touch things due the brittle nature of its hardware support. >> I noticed this too. And every time it struck me as odd. >> >>> 2) i was in need to an *affordable* machine with a warranty. >>> fortunately >>> there are many affordable laptops at staples, best-buy and amazon - but >>> >>> they were all post haswell systems, rendering them basically useless >> >from a FreeBSD perspective. >> >> Which is why removing drm2 was necessary. >> >>> after trying to get traction to update the in-tree drm subsystem i was >>> lucky enough to sync up with the graphics team which was working on >>> syncing things up with modern hardware support. because of that i'm >>> now >>> able to get my small startup pretty much all on board with FreeBSD. i >>> use it on my workstations as well as on or server infrastructure >>> (physical and AWS). i would consider this a success for our community >>> as it's opened up the eyes to a whole new generation of devs to >>> FreeBSD. >>> >>> one thing missing from all of these arguments is real data. how many >>> people are on haswell era hardware? i can tell from my experience the >>> past several years the number of people who have post-haswell gear seem >>> >>> to be more numerous, or at least more vocal (and frankly easier to work >>> >>> with while squashing bugs). >>> >>> i can also say that personally it would be great to improve support for >>> >>> systems requiring drm2 - but that gear is hard to come by, so we are >>> really dependent on helpful collaboration from those who are being >>> effected. >> Drm2 is not required. My current laptop is 5 years old, an HD3000. The >> previous one is 13 years old, i915. Both work perfectly with drm-current on >> 13-current. Franky, I don't see what the fuss is about. >> >> > My Dell Latitude D530 running i386 freebsd, which used the > i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs > non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. > It seems that Niclas has provided a patch that fixes the building > of drm-legacy-kmod. > > Doing a bisection on /usr/src commits is fairly slow as it > takes a day to build world/kernel and the minimum set of ports > need to fire up Xorg. r343543 and earlier appear to work fine > with drm-legacy-kmod. So it's not only a build error, it's also a runtime bug that would have happened even with drm2 in base? Hmm.. > > I have now lost 2 weeks of hacking time that could have been spent > on the missing C99 complex math routines. Yeah it sucks when you have to get your hands dirty and actually contribute yourself to keep the code you use alive and no one else does it for you... How many hours do you think we have lost dealing with all the whining and complaining on the mailing list where we instead could have done productive work? > Yeah, I know very few > people care about numerical simulations on FreeBSD. > ___ freebsd-current@freebsd.org mailing list
Re: What is evdev and autoloading?
On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote: > On February 18, 2019 9:17:37 AM PST, Pete Wright wrote: > > > > > >On 2/18/19 8:50 AM, Rodney W. Grimes wrote: > >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < > >>> > >>> I don't know. I think the fact that drm2 doesn't support anything > >newer > >>> than 5-year-old hardware is a pretty convincing evidence that the > >old way > >>> is broken and doesn't work. > >> But it DOES work, I am pretty sure we have 1000's of users on that 5 > >year > >> old hardware that are totally happy with the intree DRM2 that is in > >stable/12, > >> and some of whom have ventured into head/13 are having issues with > >thete a > >> "new" model (ie kmod broken by a base commit). I know that there is > >wip > >> to get CI coverage for that, but wip is wip, and we need to start > >changing > >> the cart horse driver order we keep doing and get things right. Port > >> up and working, with CI testing *before* we go remove kmod'ed code > >from > >> base would be a much more appropriate path. > >> > >> I think one serious problem here is the summary dismissal of things > >> simply on the "5 year old" basis. Not everyone, and infact few now > >> a days other than corporate buyers, can afford new hardware, > >> giving the minimal performance increase in systems over the last 5 > >> years the cost/benifit factor of a new computer is just too low. > >I've put a lot of effort helping test and document how to get a usable > >desktop environment on a modern laptop. there were two issues which > >motivated me to do this: > > > >1) my observation that many developers at conferences and online were > >using macOS as their primary desktop environment. when comparing this > >to the OpenBSD and Linux community I felt pretty embarrassed, but it > >did > >explain the stagnant nature of our graphics subsystem. people seemed > >afraid to touch things due the brittle nature of its hardware support. > > I noticed this too. And every time it struck me as odd. > > > > >2) i was in need to an *affordable* machine with a warranty. > >fortunately > >there are many affordable laptops at staples, best-buy and amazon - but > > > >they were all post haswell systems, rendering them basically useless > >from a FreeBSD perspective. > > Which is why removing drm2 was necessary. > > > > >after trying to get traction to update the in-tree drm subsystem i was > >lucky enough to sync up with the graphics team which was working on > >syncing things up with modern hardware support. because of that i'm > >now > >able to get my small startup pretty much all on board with FreeBSD. i > >use it on my workstations as well as on or server infrastructure > >(physical and AWS). i would consider this a success for our community > >as it's opened up the eyes to a whole new generation of devs to > >FreeBSD. > > > >one thing missing from all of these arguments is real data. how many > >people are on haswell era hardware? i can tell from my experience the > >past several years the number of people who have post-haswell gear seem > > > >to be more numerous, or at least more vocal (and frankly easier to work > > > >with while squashing bugs). > > > >i can also say that personally it would be great to improve support for > > > >systems requiring drm2 - but that gear is hard to come by, so we are > >really dependent on helpful collaboration from those who are being > >effected. > > Drm2 is not required. My current laptop is 5 years old, an HD3000. The > previous one is 13 years old, i915. Both work perfectly with drm-current on > 13-current. Franky, I don't see what the fuss is about. > > My Dell Latitude D530 running i386 freebsd, which used the i915kms.ko now locks up solid with drm-legacy-kmod. The PAE vs non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod. It seems that Niclas has provided a patch that fixes the building of drm-legacy-kmod. Doing a bisection on /usr/src commits is fairly slow as it takes a day to build world/kernel and the minimum set of ports need to fire up Xorg. r343543 and earlier appear to work fine with drm-legacy-kmod. I have now lost 2 weeks of hacking time that could have been spent on the missing C99 complex math routines. Yeah, I know very few people care about numerical simulations on FreeBSD. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On February 18, 2019 9:17:37 AM PST, Pete Wright wrote: > > >On 2/18/19 8:50 AM, Rodney W. Grimes wrote: >>> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >>> >>> I don't know. I think the fact that drm2 doesn't support anything >newer >>> than 5-year-old hardware is a pretty convincing evidence that the >old way >>> is broken and doesn't work. >> But it DOES work, I am pretty sure we have 1000's of users on that 5 >year >> old hardware that are totally happy with the intree DRM2 that is in >stable/12, >> and some of whom have ventured into head/13 are having issues with >thete a >> "new" model (ie kmod broken by a base commit). I know that there is >wip >> to get CI coverage for that, but wip is wip, and we need to start >changing >> the cart horse driver order we keep doing and get things right. Port >> up and working, with CI testing *before* we go remove kmod'ed code >from >> base would be a much more appropriate path. >> >> I think one serious problem here is the summary dismissal of things >> simply on the "5 year old" basis. Not everyone, and infact few now >> a days other than corporate buyers, can afford new hardware, >> giving the minimal performance increase in systems over the last 5 >> years the cost/benifit factor of a new computer is just too low. >I've put a lot of effort helping test and document how to get a usable >desktop environment on a modern laptop. there were two issues which >motivated me to do this: > >1) my observation that many developers at conferences and online were >using macOS as their primary desktop environment. when comparing this >to the OpenBSD and Linux community I felt pretty embarrassed, but it >did >explain the stagnant nature of our graphics subsystem. people seemed >afraid to touch things due the brittle nature of its hardware support. I noticed this too. And every time it struck me as odd. > >2) i was in need to an *affordable* machine with a warranty. >fortunately >there are many affordable laptops at staples, best-buy and amazon - but > >they were all post haswell systems, rendering them basically useless >from a FreeBSD perspective. Which is why removing drm2 was necessary. > >after trying to get traction to update the in-tree drm subsystem i was >lucky enough to sync up with the graphics team which was working on >syncing things up with modern hardware support. because of that i'm >now >able to get my small startup pretty much all on board with FreeBSD. i >use it on my workstations as well as on or server infrastructure >(physical and AWS). i would consider this a success for our community >as it's opened up the eyes to a whole new generation of devs to >FreeBSD. > >one thing missing from all of these arguments is real data. how many >people are on haswell era hardware? i can tell from my experience the >past several years the number of people who have post-haswell gear seem > >to be more numerous, or at least more vocal (and frankly easier to work > >with while squashing bugs). > >i can also say that personally it would be great to improve support for > >systems requiring drm2 - but that gear is hard to come by, so we are >really dependent on helpful collaboration from those who are being >effected. Drm2 is not required. My current laptop is 5 years old, an HD3000. The previous one is 13 years old, i915. Both work perfectly with drm-current on 13-current. Franky, I don't see what the fuss is about. > > >-pete > >-- >Pete Wright >p...@nomadlogic.org >@nomadlogicLA > >___ >freebsd-current@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to >"freebsd-current-unsubscr...@freebsd.org" The only irritation with drm-current is after doing a NO_CLEAN build ARC is large enough that on occasion a video may not play because X is unable to get the memory. Other than that it works better than drm-legacy -- with no artifacts. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Tue, Feb 19, 2019 at 06:25:32AM -0800, Rodney W. Grimes wrote: > We are certainly driving users away by our operation model If you want to help take up more support duties -- especially for aging hardware -- I doubt anyone would stop you. There is plenty of work to take up; just check Bugzilla. > This is not some leap forward for anyone Nonsense. > and definitely a slight step backwards for some, many, who knows, > I put it in the 1000s of users. Utter nonsense. Right now we see the the following case: "latest graphics fail to work on i386 laptops". I fail to believe that is more than a handful of users. mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Tue, 19 Feb 2019 06:25:32 -0800 (PST) "Rodney W. Grimes" wrote: > > > On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko wrote: > > > > > > Michael Gmelin (gre...@freebsd.org) wrote: > > >> > > >> > > On 18. Feb 2019, at 23:54, Mark Linimon 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. > > --
Re: What is evdev and autoloading?
On Tue, Feb 19, 2019 at 8:17 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko > wrote: > > > > > > Michael Gmelin (gre...@freebsd.org) wrote: > > >> > > >> > > On 18. Feb 2019, at 23:54, Mark Linimon > 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. > Yes. Those in-base drivers don't work. Or rather don't work well. The kinda sorta work for some people, but there's a huge number of kludges and hacks the graphics guys have been doing to keep it going and it's too much. Those hacks, like needing to make xf86-video-ati-legacy, like hacking back in support for drm2 in mesa which has moved on to requiring, basically drm3, like looking at issues that arise from there being regressions in drm-kmod on some older hardware. It's too much. There's lots of duct-tape and bailing wire that you don't see that's necessary to keep it going. That's the real bottom line here, whether you want to accept this harsh reality or not: we simply do not have the resources to continue to support drm2. I deleted the rest of your rant. It's not worth answering point by point. Things aren't like you think they are, and if the many polite (and not so polite) explanations haven't sunk in, another round sure won't help. drm2 is dead. The decision was made months ago. The game is finally over. I'll be committing the removal later today. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 01:43:22PM +0100, Niclas Zeising wrote: > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > >On 2/18/19, Vladimir Kondratyev wrote: > >>On 2019-02-17 21:03, Steve Kargl wrote: > >>>Anyone have insight into what evdev is? > >>evdev.ko is a small in-kernel library that makes all your input events > >>like keyboard presses libinput-compatible. > > > >And libinput was created by the Freedesktop Wayland team to create > >pressure on OS people to make their systems Wayland-compatible. > > > >>>I do not need nor what these modules loaded. > >>I think removing "option EVDEV_SUPPORT" from your kernel config should > >>disable most of evdev.ko dependencies > > > >Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > >as libinput not be part of the standard packages? > > > >The Freedesktop Wayland team consists of people with the Kay Sievers > >mentality, which made Linus Torvalds ban his contributions. They do > >not care about the bugs they introduce, forcing others to clean up the > >mess they create. > > > >I'd be glad if FreeBSD would keep clean of following that Wayland fad... > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > input device handling in X and Wayland. Not having it means that a lot > of input devices stop working, or work much worse. I use it to run a wmt(4) touchpanel display, which wouldn't work otherwise. I have to say that I kind of like the evdev system as it also makes it very easy to place events from userland processes. What I don't like is that we had no autosetup support in XOrg when I first used it - in the meantime this might have changed however. > > We in the FreeBSD Graphics Team are working very hard to improve the > FreeBSD Desktop experience, since it is an avenue to recruit new users, > and make current users use FreeBSD more. > > Evdev and libinput is used by both Wayland and xorg. You are free to > use either one. > > Regards > -- > Niclas Zeising > FreeBSD Graphics Team > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
> > On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko wrote: > > > > Michael Gmelin (gre...@freebsd.org) wrote: > >> > >> > On 18. Feb 2019, at 23:54, Mark Linimon 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 rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
> On 19 Feb 2019, at 09.15, Oleksandr Tymoshenko wrote: > > Michael Gmelin (gre...@freebsd.org) wrote: >> >> On 18. Feb 2019, at 23:54, Mark Linimon 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. >>> >>> 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. >>> >>> 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 > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/18/19 10:54 PM, Mark Linimon 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. > > 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. This! Especially, support for modern laptops is important. Personally, I don't know many developers who use a desktop PC these days (but I do respect the fact that many do - old PCs as well). My laptop builds world in 1h30m which is pretty decent. I don't feel a need at all for desktop computer and I don't want to trade away the freedom of bringing my laptop with me anywhere for work. When it comes to attracting new developers, modern laptop support also plays an important role. Without new developers coming in, this project will fade out and die. Another side of graphics which isn't discussed at all is GPU computing using technologies like Radeon Open Compute, made possible by the amdgpu driver with KFD (porting work in progress but not a priority atm). i915kms has GVT for virtualization of the GPU (porting initialized). These are pretty serious technologies that could potentially lead to good business (which is now lost to Linux). Modern graphics support isn't all about fancy desktops and spinning gears. Totally outside the topic of this thread but I felt like ranting a bit PS, if anyone want to help develop an iommu driver for amdkfd, please let us know :) Cheers! > Again all IMHO. > > disclaimer: I don't use any fancy graphics stuff, so (as the old folks > say around here) "I have no dog in this hunt". > > mcl > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
Michael Gmelin (gre...@freebsd.org) wrote: > > > > On 18. Feb 2019, at 23:54, Mark Linimon 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. > > > > 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. > > > > 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/19/19 12:37 AM, Warner Losh wrote: > On Mon, Feb 18, 2019 at 9:50 AM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > >> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote: >>> You do know these constant complaints about people trying to make things >>> better is demoralizing and counter productive. >>> >> You do realize some of the emails are from frustrated users >> who are trying to make FreeBSD (see for example libm). >> > Yes. I get that. My frustration isn't with you, or your questions. I get > why you want to run -current. I'm sorry it's being painful for you. > Sometimes, -current is like that. When this happens, there's always vesa and scfb (software rendering) to fall back to so your machine won't be rendered useless. Not saying this should be the norm, but good to know so that your work get minimal interruption. Alternatively, run experimental kernels/worlds in bhyve (what I tend to do when I want everything accessible on the same local machine). > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 9:50 AM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote: > > > > You do know these constant complaints about people trying to make things > > better is demoralizing and counter productive. > > > > You do realize some of the emails are from frustrated users > who are trying to make FreeBSD (see for example libm). > Yes. I get that. My frustration isn't with you, or your questions. I get why you want to run -current. I'm sorry it's being painful for you. Sometimes, -current is like that. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 9:50 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: > > > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > > > > > On 2/18/19, Vladimir Kondratyev > wrote: > > > > > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > > > > > >>> Anyone have insight into what evdev is? > > > > > > >> evdev.ko is a small in-kernel library that makes all your > input > > > events > > > > > > >> like keyboard presses libinput-compatible. > > > > > > > > > > > > > > And libinput was created by the Freedesktop Wayland team to > create > > > > > > > pressure on OS people to make their systems Wayland-compatible. > > > > > > > > > > > > > >>> I do not need nor what these modules loaded. > > > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel > config > > > should > > > > > > >> disable most of evdev.ko dependencies > > > > > > > > > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, > as > > > well > > > > > > > as libinput not be part of the standard packages? > > > > > > > > > > > > > > The Freedesktop Wayland team consists of people with the Kay > > > Sievers > > > > > > > mentality, which made Linus Torvalds ban his contributions. > They do > > > > > > > not care about the bugs they introduce, forcing others to > clean up > > > the > > > > > > > mess they create. > > > > > > > > > > > > > > I'd be glad if FreeBSD would keep clean of following that > Wayland > > > fad... > > > > > > > > > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to > improve > > > > > > input device handling in X and Wayland. Not having it means > that a > > > lot > > > > > > of input devices stop working, or work much worse. > > > > > > > > > > > > We in the FreeBSD Graphics Team are working very hard to improve > the > > > > > > FreeBSD Desktop experience, since it is an avenue to recruit new > > > users, > > > > > > and make current users use FreeBSD more. > > > > > > > > > > Sadly your execution on that seems to be missing the mark, > > > > > telling people they have to go get a port now to get drm working > > > > > because it could not be maintained in base, and then telling them, > > > > > oh, you need this new code in base so that it is so much easier > > > > > to use graphical stuff this way. > > > > > > > > > > These seem to be conflicting stories. > > > > > > > > > You are missing the point, one does not evolve as fast as the other, > > > meaning > > > > one can be maintained within usual freebsd lifecycle, the other > cannot > > > or it > > > > becomes very painful. > > > > > > So to ditch our 5 years support model, kick the code out of the tree > and > > > make the users suffer? The support model is suppose to be under > review, > > > and IMHO, if kicking functional code out of the base system is to make > > > it possible to meet some support model we should defanitly take a very > > > close look at that issue. > > > > > > The code has simply gone from being in base to a few git repositories > > > which are probably going to rot every time a breaking ABI change occurs > > > and we wend up with un happy users, un happy developers and bugmisters > > > who have to close bogus bug reports. > > > > > > Have we really moved the state of the art forward by this action, > simply > > > in the name of "we could not suppor that code?" > > > > > > > I don't know. I think the fact that drm2 doesn't support anything newer > > than 5-year-old hardware is a pretty convincing evidence that the old way > > is broken and doesn't work. > > But it DOES work, I am pretty sure we have 1000's of users on that 5 year > old hardware that are totally happy with the in tree DRM2 that is in > stable/12, > and some of whom have ventured into head/13 are having issues with the > "new" model (ie kmod broken by a base commit). First off, current is current. Second, they have two different drm modules to choose from. The drm-legacy stuff was broken by a commit to base, but even if it had been in base, and connected to the build, it would have been broken. kib would have fixed the compile issue (which we did fix in github almost as soon as it happend). However, the semantic issue he wouldn't have seen because he wouldn't have actually tested the setup that's broken because he doesn't have it. So please stop saying it does work. It does not work. It was silently broken by kib's changes. The compile issue is a red herring. You'd be fighting the same issue in current if it was connected to the build. It's literally the same code. > I know that there is wip > to get CI coverage for that, but wip is wip, and we need to start changing > the cart horse driver order we keep doing and get things right. Port > up and working, with CI testing *before* we go remove kmod'ed code from > base would be a
Re: What is evdev and autoloading?
> On 18. Feb 2019, at 23:54, Mark Linimon 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. > > 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. > > 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. -m ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
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. 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. Again all IMHO. disclaimer: I don't use any fancy graphics stuff, so (as the old folks say around here) "I have no dog in this hunt". mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
motivated me to do this: 1) my observation that many developers at conferences and online were using macOS as their primary desktop environment. when comparing this to the OpenBSD and Linux community I felt pretty embarrassed, but it did explain the stagnant nature of our graphics subsystem. people seemed afraid to touch things due the brittle nature of its hardware support. 2) i was in need to an *affordable* machine with a warranty. fortunately there are many affordable laptops at staples, best-buy and amazon - but they were all post haswell systems, rendering them basically useless from a FreeBSD perspective. I've bought recently (like half year ago) cheapest laptop available. Everything supported with FreeBSD out of the box, except little problem with sound but dev.hdac.0.polling=1 made it work. What a problem? Even lowest end today computer is really high end for normal programs. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/17/19 6:48 PM, Ian Lepore wrote: That manpage you found online is in section 4x. It probably gets installed along with the xf86-input-evdev package. yes - unfortunately that seems to be the only form of man page that exists on the linux side as well. did a quick search through the linux source and there is unsurprisingly a lack of coherent documentation for the evdev driver there (there is plenty online - wikipedia is a decent starting place). getting a man page is a pretty high priority and should hopefully get sorted out before 12.1-RELEASE is ready...so the system works? lol -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 02/18/19 10:50, Rodney W. Grimes wrote: >> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < >> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: >> On 2/18/19 12:06 PM, Stefan Blachmann wrote: >>> On 2/18/19, Vladimir Kondratyev wrote: On 2019-02-17 21:03, Steve Kargl wrote: > Anyone have insight into what evdev is? evdev.ko is a small in-kernel library that makes all your input >>> events like keyboard presses libinput-compatible. That's... wrong. evdev has nothing to do with libinput. Rather, it can be used by libinput, but I never once used libinput on FreeBSD/X11. I used xf86-input-evdev. evdev is a generic event device subsystem originated in the Linux kernel. > But it DOES work, I am pretty sure we have 1000's of users on that 5 year > old hardware that are totally happy with the intree DRM2 that is in stable/12, > and some of whom have ventured into head/13 are having issues with the > "new" model (ie kmod broken by a base commit). > > I think one serious problem here is the summary dismissal of things > simply on the "5 year old" basis. Not everyone, and infact few now > a days other than corporate buyers, can afford new hardware, > giving the minimal performance increase in systems over the last 5 > years the cost/benifit factor of a new computer is just too low. That's the primary reason I don't focus on FreeBSD any more, and the primary reason when I have sudden time crunches, FreeBSD stuff is the first to go out the window. It's not that I don't like FreeBSD any more, it's that it just doesn't fit in with my ideas on how a system project should be run, or how it should prioritise. And that isn't really a comment on FreeBSD, nor me, it's just a statement. Everyone's different. Perhaps all the people who are upset at FreeBSD becoming the next OS X (you must have hardware *this* *new* to run!) should start putting more effort in to keeping the old hardware alive and working in the processes defined by FreeBSD. Make proposals, participate and communicate on MLs (instead of just complain), etc. This is all just observations I've made over the last few months of reading -current and not really contributing much. Apologies if I'm off the mark on any of this. Best to you and yours, --arw -- A. Wilcox (awilfox) Open-source programmer (C, C++, Python) https://code.foxkit.us/u/awilfox/ signature.asc Description: OpenPGP digital signature
Re: What is evdev and autoloading?
On 2/18/19 8:50 AM, Rodney W. Grimes wrote: On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < I don't know. I think the fact that drm2 doesn't support anything newer than 5-year-old hardware is a pretty convincing evidence that the old way is broken and doesn't work. But it DOES work, I am pretty sure we have 1000's of users on that 5 year old hardware that are totally happy with the intree DRM2 that is in stable/12, and some of whom have ventured into head/13 are having issues with thete a "new" model (ie kmod broken by a base commit). I know that there is wip to get CI coverage for that, but wip is wip, and we need to start changing the cart horse driver order we keep doing and get things right. Port up and working, with CI testing *before* we go remove kmod'ed code from base would be a much more appropriate path. I think one serious problem here is the summary dismissal of things simply on the "5 year old" basis. Not everyone, and infact few now a days other than corporate buyers, can afford new hardware, giving the minimal performance increase in systems over the last 5 years the cost/benifit factor of a new computer is just too low. I've put a lot of effort helping test and document how to get a usable desktop environment on a modern laptop. there were two issues which motivated me to do this: 1) my observation that many developers at conferences and online were using macOS as their primary desktop environment. when comparing this to the OpenBSD and Linux community I felt pretty embarrassed, but it did explain the stagnant nature of our graphics subsystem. people seemed afraid to touch things due the brittle nature of its hardware support. 2) i was in need to an *affordable* machine with a warranty. fortunately there are many affordable laptops at staples, best-buy and amazon - but they were all post haswell systems, rendering them basically useless from a FreeBSD perspective. after trying to get traction to update the in-tree drm subsystem i was lucky enough to sync up with the graphics team which was working on syncing things up with modern hardware support. because of that i'm now able to get my small startup pretty much all on board with FreeBSD. i use it on my workstations as well as on or server infrastructure (physical and AWS). i would consider this a success for our community as it's opened up the eyes to a whole new generation of devs to FreeBSD. one thing missing from all of these arguments is real data. how many people are on haswell era hardware? i can tell from my experience the past several years the number of people who have post-haswell gear seem to be more numerous, or at least more vocal (and frankly easier to work with while squashing bugs). i can also say that personally it would be great to improve support for systems requiring drm2 - but that gear is hard to come by, so we are really dependent on helpful collaboration from those who are being effected. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/18/19 3:12 PM, Rodney W. Grimes wrote: >> On 2/18/19 12:06 PM, Stefan Blachmann wrote: >>> On 2/18/19, Vladimir Kondratyev wrote: On 2019-02-17 21:03, Steve Kargl wrote: > Anyone have insight into what evdev is? evdev.ko is a small in-kernel library that makes all your input events like keyboard presses libinput-compatible. >>> And libinput was created by the Freedesktop Wayland team to create >>> pressure on OS people to make their systems Wayland-compatible. >>> > I do not need nor what these modules loaded. I think removing "option EVDEV_SUPPORT" from your kernel config should disable most of evdev.ko dependencies >>> Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well >>> as libinput not be part of the standard packages? >>> >>> The Freedesktop Wayland team consists of people with the Kay Sievers >>> mentality, which made Linus Torvalds ban his contributions. They do >>> not care about the bugs they introduce, forcing others to clean up the >>> mess they create. >>> >>> I'd be glad if FreeBSD would keep clean of following that Wayland fad... >> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve >> input device handling in X and Wayland. Not having it means that a lot >> of input devices stop working, or work much worse. >> >> We in the FreeBSD Graphics Team are working very hard to improve the >> FreeBSD Desktop experience, since it is an avenue to recruit new users, >> and make current users use FreeBSD more. > Sadly your execution on that seems to be missing the mark, > telling people they have to go get a port now to get drm working > because it could not be maintained in base, and then telling them, > oh, you need this new code in base so that it is so much easier > to use graphical stuff this way. > > These seem to be conflicting stories. You don't need evdev or libinput to have a functional desktop with a 3-button mouse but some modern desktop environments require it. Why should we not include the large group of people who want to run a modern desktop? Including more users does not mean excluding anyone in this case. > >> Evdev and libinput is used by both Wayland and xorg. You are free to >> use either one. > And sadly now must take action when no action was required before > when using neither. Take what action? If you don't need it, just don't use it. If you don't want change, stay on older release. If you are a purist and want to remove everything in the kernel you don't use, you probably already have your custom kernel config, and you probably are a minority. Consider the well-being, progress and future of the project and the community at large instead of your ego. > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 09:35:26AM -0700, Warner Losh wrote: > On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl < > s...@troutmask.apl.washington.edu> wrote: > > > Anyone have insight into what evdev is? There appears to > > be no manual page. When I reboot a system with custom > > kernel, the system is autoloading evdev.ko, uhid.ko, and > > wmt.ko. I do not need nor what these modules loaded. > > How does one prevent this autoloading? > > > > > This thread has taken a weird turn, so I went back to the original post. > > When do these things get loaded? Is it when you start up X11? Or is it > being brought in by devmatch? If it is being brought in by x11, there's > likely an x11 config that you'll need to avoid them (but that will reduce > functionality). If it is devmatch, then you can add them to the black list > and have them not load them. > I think it is devmatch (or at least devd.conf related). I have a wireless USB logitch mouse. If I unplug the dongle from its port and reboot, evdev.ko, uhid.ko, and wmt.ko do not get loaded. When I plug in the dongle, the 3 get loaded. I can kldunload wmt and evdev, but as soon as the mouse is moved both are reloaded. ums(4) does not mention any of these devices as a requirement. wmt(4) says it only works for touchscreen. This laptop pre-dates touchscreens, so loading the module is simply wasteful. There is no evdev(4), so can't determine what it is or does. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 09:58:14AM -0700, Ian Lepore wrote: > On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote: > > On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote: > > > > > > You do know these constant complaints about people trying to make > > > things > > > better is demoralizing and counter productive. > > > > > > > You do realize some of the emails are from frustrated users > > who are trying to make FreeBSD (see for example libm). > > > > And do you realize that you've trimmed away all the context so that now > it looks like Warner was talking to you, when in fact he was replying > to Rod? I sure hope that was an accident. > Thanks for your considered input. It has been noted. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, 2019-02-18 at 08:50 -0800, Steve Kargl wrote: > On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote: > > > > You do know these constant complaints about people trying to make > > things > > better is demoralizing and counter productive. > > > > You do realize some of the emails are from frustrated users > who are trying to make FreeBSD (see for example libm). > And do you realize that you've trimmed away all the context so that now it looks like Warner was talking to you, when in fact he was replying to Rod? I sure hope that was an accident. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote: > > You do know these constant complaints about people trying to make things > better is demoralizing and counter productive. > You do realize some of the emails are from frustrated users who are trying to make FreeBSD (see for example libm). -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: > > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > > > > On 2/18/19, Vladimir Kondratyev wrote: > > > > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > > > > >>> Anyone have insight into what evdev is? > > > > > >> evdev.ko is a small in-kernel library that makes all your input > > events > > > > > >> like keyboard presses libinput-compatible. > > > > > > > > > > > > And libinput was created by the Freedesktop Wayland team to create > > > > > > pressure on OS people to make their systems Wayland-compatible. > > > > > > > > > > > >>> I do not need nor what these modules loaded. > > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config > > should > > > > > >> disable most of evdev.ko dependencies > > > > > > > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as > > well > > > > > > as libinput not be part of the standard packages? > > > > > > > > > > > > The Freedesktop Wayland team consists of people with the Kay > > Sievers > > > > > > mentality, which made Linus Torvalds ban his contributions. They do > > > > > > not care about the bugs they introduce, forcing others to clean up > > the > > > > > > mess they create. > > > > > > > > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland > > fad... > > > > > > > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > > > > > input device handling in X and Wayland. Not having it means that a > > lot > > > > > of input devices stop working, or work much worse. > > > > > > > > > > We in the FreeBSD Graphics Team are working very hard to improve the > > > > > FreeBSD Desktop experience, since it is an avenue to recruit new > > users, > > > > > and make current users use FreeBSD more. > > > > > > > > Sadly your execution on that seems to be missing the mark, > > > > telling people they have to go get a port now to get drm working > > > > because it could not be maintained in base, and then telling them, > > > > oh, you need this new code in base so that it is so much easier > > > > to use graphical stuff this way. > > > > > > > > These seem to be conflicting stories. > > > > > > > You are missing the point, one does not evolve as fast as the other, > > meaning > > > one can be maintained within usual freebsd lifecycle, the other cannot > > or it > > > becomes very painful. > > > > So to ditch our 5 years support model, kick the code out of the tree and > > make the users suffer? The support model is suppose to be under review, > > and IMHO, if kicking functional code out of the base system is to make > > it possible to meet some support model we should defanitly take a very > > close look at that issue. > > > > The code has simply gone from being in base to a few git repositories > > which are probably going to rot every time a breaking ABI change occurs > > and we wend up with un happy users, un happy developers and bugmisters > > who have to close bogus bug reports. > > > > Have we really moved the state of the art forward by this action, simply > > in the name of "we could not suppor that code?" > > > > I don't know. I think the fact that drm2 doesn't support anything newer > than 5-year-old hardware is a pretty convincing evidence that the old way > is broken and doesn't work. But it DOES work, I am pretty sure we have 1000's of users on that 5 year old hardware that are totally happy with the intree DRM2 that is in stable/12, and some of whom have ventured into head/13 are having issues with the "new" model (ie kmod broken by a base commit). I know that there is wip to get CI coverage for that, but wip is wip, and we need to start changing the cart horse driver order we keep doing and get things right. Port up and working, with CI testing *before* we go remove kmod'ed code from base would be a much more appropriate path. I think one serious problem here is the summary dismissal of things simply on the "5 year old" basis. Not everyone, and infact few now a days other than corporate buyers, can afford new hardware, giving the minimal performance increase in systems over the last 5 years the cost/benifit factor of a new computer is just too low. One of the long standing features of running a BSD is that it could stretch very good life out of hardware, and imho it would be in our best interest to try and keep that. And we do in most aspects, though recently in some hardware testing OpenBSD beat us in several cases of "just booted and worked" on several pieces of hardware that came accross my bench for data recovery. FreeBSD would not even boot, or paniced early in the kernel :-( None of these systems was older than a P4. > Warner -- Rod Grimes rgri...@freebsd.org ___
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 09:32:52AM -0700, Warner Losh wrote: > On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > So to ditch our 5 years support model, kick the code out of the tree and > > make the users suffer? The support model is suppose to be under review, > > and IMHO, if kicking functional code out of the base system is to make > > it possible to meet some support model we should defanitly take a very > > close look at that issue. > > > > The code has simply gone from being in base to a few git repositories > > which are probably going to rot every time a breaking ABI change occurs > > and we wend up with un happy users, un happy developers and bugmisters > > who have to close bogus bug reports. > > > > Have we really moved the state of the art forward by this action, simply > > in the name of "we could not suppor that code?" > > > > I don't know. I think the fact that drm2 doesn't support anything newer > than 5-year-old hardware is a pretty convincing evidence that the old way > is broken and doesn't work. > When drm2 was unhooked from the build, it was working fine. drm2 was unhooked because it supposedly interferred with the drm-stable-kmod and drm-current-kmod ports. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 04:56:57PM +0100, Baptiste Daroussin wrote:
> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote:
> >
> > Sadly your execution on that seems to be missing the mark,
> > telling people they have to go get a port now to get drm working
> > because it could not be maintained in base, and then telling them,
> > oh, you need this new code in base so that it is so much easier
> > to use graphical stuff this way.
> >
> > These seem to be conflicting stories.
> >
> You are missing the point, one does not evolve as fast as the other, meaning
> one can be maintained within usual freebsd lifecycle, the other cannot or it
> becomes very painful.
>
And you seem to be missing the point. I'm now in week two of
trying to figure out why drm-legacy-kmod no longer works, and
suddenly new devices are popping up which are not configured
in my kernel.
I have deleted all ports. I have delete /usr/src and /usr/obj.
I used svn to pull a -r "{2019-01-01}" /usr/src. That builds
and works fine. I then build the minimum ports needs to install
drm-legacy-kmod and xorg. I can fire a fvwm2 desktop. I'm now
up to -r "{2019-01-28}". Yes, bi-section be date. It takes 6-7
hours to rebuild world and kernel and another hour or 2 for the
minimum set of ports.
PS: It still does answer why there isn't a manual page for evdev.
--
steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Sun, Feb 17, 2019 at 3:52 PM Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > Anyone have insight into what evdev is? There appears to > be no manual page. When I reboot a system with custom > kernel, the system is autoloading evdev.ko, uhid.ko, and > wmt.ko. I do not need nor what these modules loaded. > How does one prevent this autoloading? > Hi Steve, This thread has taken a weird turn, so I went back to the original post. When do these things get loaded? Is it when you start up X11? Or is it being brought in by devmatch? If it is being brought in by x11, there's likely an x11 config that you'll need to avoid them (but that will reduce functionality). If it is devmatch, then you can add them to the black list and have them not load them. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: > > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > > > On 2/18/19, Vladimir Kondratyev wrote: > > > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > > > >>> Anyone have insight into what evdev is? > > > > >> evdev.ko is a small in-kernel library that makes all your input > events > > > > >> like keyboard presses libinput-compatible. > > > > > > > > > > And libinput was created by the Freedesktop Wayland team to create > > > > > pressure on OS people to make their systems Wayland-compatible. > > > > > > > > > >>> I do not need nor what these modules loaded. > > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config > should > > > > >> disable most of evdev.ko dependencies > > > > > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as > well > > > > > as libinput not be part of the standard packages? > > > > > > > > > > The Freedesktop Wayland team consists of people with the Kay > Sievers > > > > > mentality, which made Linus Torvalds ban his contributions. They do > > > > > not care about the bugs they introduce, forcing others to clean up > the > > > > > mess they create. > > > > > > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland > fad... > > > > > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > > > > input device handling in X and Wayland. Not having it means that a > lot > > > > of input devices stop working, or work much worse. > > > > > > > > We in the FreeBSD Graphics Team are working very hard to improve the > > > > FreeBSD Desktop experience, since it is an avenue to recruit new > users, > > > > and make current users use FreeBSD more. > > > > > > Sadly your execution on that seems to be missing the mark, > > > telling people they have to go get a port now to get drm working > > > because it could not be maintained in base, and then telling them, > > > oh, you need this new code in base so that it is so much easier > > > to use graphical stuff this way. > > > > > > These seem to be conflicting stories. > > > > > You are missing the point, one does not evolve as fast as the other, > meaning > > one can be maintained within usual freebsd lifecycle, the other cannot > or it > > becomes very painful. > > So to ditch our 5 years support model, kick the code out of the tree and > make the users suffer? The support model is suppose to be under review, > and IMHO, if kicking functional code out of the base system is to make > it possible to meet some support model we should defanitly take a very > close look at that issue. > > The code has simply gone from being in base to a few git repositories > which are probably going to rot every time a breaking ABI change occurs > and we wend up with un happy users, un happy developers and bugmisters > who have to close bogus bug reports. > > Have we really moved the state of the art forward by this action, simply > in the name of "we could not suppor that code?" > I don't know. I think the fact that drm2 doesn't support anything newer than 5-year-old hardware is a pretty convincing evidence that the old way is broken and doesn't work. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
> On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: > > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > > On 2/18/19, Vladimir Kondratyev wrote: > > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > > >>> Anyone have insight into what evdev is? > > > >> evdev.ko is a small in-kernel library that makes all your input events > > > >> like keyboard presses libinput-compatible. > > > > > > > > And libinput was created by the Freedesktop Wayland team to create > > > > pressure on OS people to make their systems Wayland-compatible. > > > > > > > >>> I do not need nor what these modules loaded. > > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should > > > >> disable most of evdev.ko dependencies > > > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > > > > as libinput not be part of the standard packages? > > > > > > > > The Freedesktop Wayland team consists of people with the Kay Sievers > > > > mentality, which made Linus Torvalds ban his contributions. They do > > > > not care about the bugs they introduce, forcing others to clean up the > > > > mess they create. > > > > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad... > > > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > > > input device handling in X and Wayland. Not having it means that a lot > > > of input devices stop working, or work much worse. > > > > > > We in the FreeBSD Graphics Team are working very hard to improve the > > > FreeBSD Desktop experience, since it is an avenue to recruit new users, > > > and make current users use FreeBSD more. > > > > Sadly your execution on that seems to be missing the mark, > > telling people they have to go get a port now to get drm working > > because it could not be maintained in base, and then telling them, > > oh, you need this new code in base so that it is so much easier > > to use graphical stuff this way. > > > > These seem to be conflicting stories. > > > You are missing the point, one does not evolve as fast as the other, meaning > one can be maintained within usual freebsd lifecycle, the other cannot or it > becomes very painful. So to ditch our 5 years support model, kick the code out of the tree and make the users suffer? The support model is suppose to be under review, and IMHO, if kicking functional code out of the base system is to make it possible to meet some support model we should defanitly take a very close look at that issue. The code has simply gone from being in base to a few git repositories which are probably going to rot every time a breaking ABI change occurs and we wend up with un happy users, un happy developers and bugmisters who have to close bogus bug reports. Have we really moved the state of the art forward by this action, simply in the name of "we could not suppor that code?" -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 8:33 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > On 2/18/19, Vladimir Kondratyev wrote: > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > >>> Anyone have insight into what evdev is? > > >> evdev.ko is a small in-kernel library that makes all your input events > > >> like keyboard presses libinput-compatible. > > > > > > And libinput was created by the Freedesktop Wayland team to create > > > pressure on OS people to make their systems Wayland-compatible. > > > > > >>> I do not need nor what these modules loaded. > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should > > >> disable most of evdev.ko dependencies > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > > > as libinput not be part of the standard packages? > > > > > > The Freedesktop Wayland team consists of people with the Kay Sievers > > > mentality, which made Linus Torvalds ban his contributions. They do > > > not care about the bugs they introduce, forcing others to clean up the > > > mess they create. > > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland > fad... > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > > input device handling in X and Wayland. Not having it means that a lot > > of input devices stop working, or work much worse. > > > > We in the FreeBSD Graphics Team are working very hard to improve the > > FreeBSD Desktop experience, since it is an avenue to recruit new users, > > and make current users use FreeBSD more. > > Sadly your execution on that seems to be missing the mark, > telling people they have to go get a port now to get drm working > because it could not be maintained in base, and then telling them, > oh, you need this new code in base so that it is so much easier > to use graphical stuff this way. > The drm stuff in the tree didn't support new hardware. And the in-tree rules made it impossible to import the GPL'd graphics drivers. And the in-tree code was abandonware that worked only by accident. > These seem to be conflicting stories. > You do know these constant complaints about people trying to make things better is demoralizing and counter productive. > > > Evdev and libinput is used by both Wayland and xorg. You are free to > > use either one. > > And sadly now must take action when no action was required before > when using neither. > Oh for foxs sake. We have so much stuff in the GENERIC kernel today that this complaint rings hallow. How many desktop users benefit from TCP_OFFLOAD? How many people SCTP? How many people are using ahc, ahd, siis, mvs, ata, hptiop, esp, trm, amr, ciss, twa, mfi, cbb, pccard, cardbus, de, le, ti, ae, hme, cas, nge, sf, tl, tx, wb, all the sound drivers, or all 4 of the different virtualization environments at the same time? Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Mon, Feb 18, 2019 at 07:12:24AM -0800, Rodney W. Grimes wrote: > > On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > > On 2/18/19, Vladimir Kondratyev wrote: > > >> On 2019-02-17 21:03, Steve Kargl wrote: > > >>> Anyone have insight into what evdev is? > > >> evdev.ko is a small in-kernel library that makes all your input events > > >> like keyboard presses libinput-compatible. > > > > > > And libinput was created by the Freedesktop Wayland team to create > > > pressure on OS people to make their systems Wayland-compatible. > > > > > >>> I do not need nor what these modules loaded. > > >> I think removing "option EVDEV_SUPPORT" from your kernel config should > > >> disable most of evdev.ko dependencies > > > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > > > as libinput not be part of the standard packages? > > > > > > The Freedesktop Wayland team consists of people with the Kay Sievers > > > mentality, which made Linus Torvalds ban his contributions. They do > > > not care about the bugs they introduce, forcing others to clean up the > > > mess they create. > > > > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad... > > > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > > input device handling in X and Wayland. Not having it means that a lot > > of input devices stop working, or work much worse. > > > > We in the FreeBSD Graphics Team are working very hard to improve the > > FreeBSD Desktop experience, since it is an avenue to recruit new users, > > and make current users use FreeBSD more. > > Sadly your execution on that seems to be missing the mark, > telling people they have to go get a port now to get drm working > because it could not be maintained in base, and then telling them, > oh, you need this new code in base so that it is so much easier > to use graphical stuff this way. > > These seem to be conflicting stories. > You are missing the point, one does not evolve as fast as the other, meaning one can be maintained within usual freebsd lifecycle, the other cannot or it becomes very painful. Bapt signature.asc Description: PGP signature
Re: What is evdev and autoloading?
> On 2/18/19 12:06 PM, Stefan Blachmann wrote: > > On 2/18/19, Vladimir Kondratyev wrote: > >> On 2019-02-17 21:03, Steve Kargl wrote: > >>> Anyone have insight into what evdev is? > >> evdev.ko is a small in-kernel library that makes all your input events > >> like keyboard presses libinput-compatible. > > > > And libinput was created by the Freedesktop Wayland team to create > > pressure on OS people to make their systems Wayland-compatible. > > > >>> I do not need nor what these modules loaded. > >> I think removing "option EVDEV_SUPPORT" from your kernel config should > >> disable most of evdev.ko dependencies > > > > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > > as libinput not be part of the standard packages? > > > > The Freedesktop Wayland team consists of people with the Kay Sievers > > mentality, which made Linus Torvalds ban his contributions. They do > > not care about the bugs they introduce, forcing others to clean up the > > mess they create. > > > > I'd be glad if FreeBSD would keep clean of following that Wayland fad... > > EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve > input device handling in X and Wayland. Not having it means that a lot > of input devices stop working, or work much worse. > > We in the FreeBSD Graphics Team are working very hard to improve the > FreeBSD Desktop experience, since it is an avenue to recruit new users, > and make current users use FreeBSD more. Sadly your execution on that seems to be missing the mark, telling people they have to go get a port now to get drm working because it could not be maintained in base, and then telling them, oh, you need this new code in base so that it is so much easier to use graphical stuff this way. These seem to be conflicting stories. > > Evdev and libinput is used by both Wayland and xorg. You are free to > use either one. And sadly now must take action when no action was required before when using neither. -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Fwd: What is evdev and autoloading?
Missed to include current@ Forwarded Message Subject:Re: What is evdev and autoloading? Date: Mon, 18 Feb 2019 12:02:50 + From: Johannes Lundberg To: freebsd-hack...@freebsd.org On 2/18/19 11:06 AM, Stefan Blachmann wrote: > On 2/18/19, Vladimir Kondratyev wrote: >> On 2019-02-17 21:03, Steve Kargl wrote: >>> Anyone have insight into what evdev is? >> evdev.ko is a small in-kernel library that makes all your input events >> like keyboard presses libinput-compatible. > And libinput was created by the Freedesktop Wayland team to create > pressure on OS people to make their systems Wayland-compatible. > >>> I do not need nor what these modules loaded. >> I think removing "option EVDEV_SUPPORT" from your kernel config should >> disable most of evdev.ko dependencies > Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well > as libinput not be part of the standard packages? Evdev with libinput provide things like, multitouch gestures, horizontal scrolling, touchpad support, etc, i.e. functionality that one might expect from a laptop or desktop computer newer than 10 years, also for X11. Having it enabled by default doesn't force you to use it but it makes it a whole lot easier for all of those who want to use it. Please try to consider what is the best middle ground for ALL users. If you have a special application for FreeBSD you're probably building your own kernel anyway and it is easy to disable if needed. Most normal (and especially new to FreeBSD) desktop/laptop users use stock kernel and would benefit from having access to this functionality. Cheers > The Freedesktop Wayland team consists of people with the Kay Sievers > mentality, which made Linus Torvalds ban his contributions. They do > not care about the bugs they introduce, forcing others to clean up the > mess they create. > > I'd be glad if FreeBSD would keep clean of following that Wayland fad... > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/18/19 12:06 PM, Stefan Blachmann wrote: On 2/18/19, Vladimir Kondratyev wrote: On 2019-02-17 21:03, Steve Kargl wrote: Anyone have insight into what evdev is? evdev.ko is a small in-kernel library that makes all your input events like keyboard presses libinput-compatible. And libinput was created by the Freedesktop Wayland team to create pressure on OS people to make their systems Wayland-compatible. I do not need nor what these modules loaded. I think removing "option EVDEV_SUPPORT" from your kernel config should disable most of evdev.ko dependencies Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well as libinput not be part of the standard packages? The Freedesktop Wayland team consists of people with the Kay Sievers mentality, which made Linus Torvalds ban his contributions. They do not care about the bugs they introduce, forcing others to clean up the mess they create. I'd be glad if FreeBSD would keep clean of following that Wayland fad... EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve input device handling in X and Wayland. Not having it means that a lot of input devices stop working, or work much worse. We in the FreeBSD Graphics Team are working very hard to improve the FreeBSD Desktop experience, since it is an avenue to recruit new users, and make current users use FreeBSD more. Evdev and libinput is used by both Wayland and xorg. You are free to use either one. Regards -- Niclas Zeising FreeBSD Graphics Team ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2/18/19, Vladimir Kondratyev wrote: > On 2019-02-17 21:03, Steve Kargl wrote: >> Anyone have insight into what evdev is? > evdev.ko is a small in-kernel library that makes all your input events > like keyboard presses libinput-compatible. And libinput was created by the Freedesktop Wayland team to create pressure on OS people to make their systems Wayland-compatible. >> I do not need nor what these modules loaded. > I think removing "option EVDEV_SUPPORT" from your kernel config should > disable most of evdev.ko dependencies Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well as libinput not be part of the standard packages? The Freedesktop Wayland team consists of people with the Kay Sievers mentality, which made Linus Torvalds ban his contributions. They do not care about the bugs they introduce, forcing others to clean up the mess they create. I'd be glad if FreeBSD would keep clean of following that Wayland fad... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2019-Feb-17, at 18:35, Rodney W. Grimes wrote: >> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote: >>> >>> >>> On 2019-Feb-17, at 10:03, Steve Kargl >>> wrote: >>> >>> Anyone have insight into what evdev is? There appears to >>> be no manual page. When I reboot a system with custom >>> kernel, the system is autoloading evdev.ko, uhid.ko, and >>> wmt.ko. I do not need nor what these modules loaded. >>> How does one prevent this autoloading? >>> >>> Looking via the web lead to: > ^^^ > web lies The URL I listed (below) is to www.freebsd.org/cgi/man.cgi?query. . . and I looked at the page's content before sending the message. That is how I got the text that I quoted. (It is from section 4 "special files".) The freeBSD manpage servers might provide more man pages than are installed? >>> >>> https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html >>> So: >>> >>> NAME >>> evdev - Generic Linux input driver >>> >>> DESCRIPTION >>> >>> evdev is an Xorg input driver for Linux's generic event devices. It >>> therefore supports all input devices that the kernel knows about, >>> including most mice, keyboards, tablets and touchscreens. evdev >>> is the default driver on the major Linux distributions. >>> . . . >>> >>> >>> >>> but it seems to not have a 13-current entry. It does have >>> a 12.0-RELEASE entry. >>> >> >> Thanks. Kinda odd that freebsd-current doesn't have a manual >> page, but FreeBSD-12 does. > > rgrimes@t400:~ % man evdev > No manual entry for evdev > rgrimes@t400:~ % man -k evdev > apropos: nothing appropriate > rgrimes@t400:~ % uname -a > FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC amd64 > rgrimes@t400:~ % > There is no man page for evdev in 12.0-RELEASE > >> >> I have a wireless logitech mouse. It seems that the >> wireless USB dongle is causing the load of the modules. >> I still understand why as ums(4) does not should a >> dependency on uhid, wmt, or evdev. > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Sun, 17 Feb 2019 18:35:25 -0800 (PST) "Rodney W. Grimes" wrote: > > On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote: > > > > > > > > > On 2019-Feb-17, at 10:03, Steve Kargl > > troutmask.apl.washington.edu> wrote: > > > > > > Anyone have insight into what evdev is? There appears to > > > be no manual page. When I reboot a system with custom > > > kernel, the system is autoloading evdev.ko, uhid.ko, and > > > wmt.ko. I do not need nor what these modules loaded. > > > How does one prevent this autoloading? > > > > > > Looking via the web lead to: > ^^^ > web lies > > > > > > > https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html > > > So: > > > > > > NAME > > >evdev - Generic Linux input driver > > > > > > DESCRIPTION > > > > > > evdev is an Xorg input driver for Linux's generic event devices. > > > It therefore supports all input devices that the kernel knows > > > about, including most mice, keyboards, tablets and touchscreens. evdev > > > is the default driver on the major Linux distributions. > > > . . . > > > > > > > > > > > > but it seems to not have a 13-current entry. It does have > > > a 12.0-RELEASE entry. > > > > > > > Thanks. Kinda odd that freebsd-current doesn't have a manual > > page, but FreeBSD-12 does. > > rgrimes@t400:~ % man evdev > No manual entry for evdev > rgrimes@t400:~ % man -k evdev > apropos: nothing appropriate > rgrimes@t400:~ % uname -a > FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC amd64 > rgrimes@t400:~ % > There is no man page for evdev in 12.0-RELEASE > > > > > I have a wireless logitech mouse. It seems that the > > wireless USB dongle is causing the load of the modules. > > I still understand why as ums(4) does not should a > > dependency on uhid, wmt, or evdev. > > > Nor 12-STABLE: root@freyja:/usr/src # man -k evdev apropos: nothing appropriate FreeBSD 12.0-STABLE #290 r344158: Fri Feb 15 14:42:58 CET 2019 amd64 Kind regards, oh ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Sun, 2019-02-17 at 16:24 -0800, Steve Kargl wrote: > On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote: > > > > > > On 2019-Feb-17, at 10:03, Steve Kargl > troutmask.apl.washington.edu> wrote: > > > > Anyone have insight into what evdev is? There appears to > > be no manual page. When I reboot a system with custom > > kernel, the system is autoloading evdev.ko, uhid.ko, and > > wmt.ko. I do not need nor what these modules loaded. > > How does one prevent this autoloading? > > > > Looking via the web lead to: > > > > https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html > > So: > > > > NAME > >evdev - Generic Linux input driver > > > > DESCRIPTION > > > > evdev is an Xorg input driver for Linux's generic event > > devices. It > > therefore supports all input devices that the kernel kn > > ows about, > > including most mice, keyboards, tablets and touchscreens. evdev > > is the default driver on the major Linux distributions. > > . . . > > > > > > > > but it seems to not have a 13-current entry. It does have > > a 12.0-RELEASE entry. > > > > Thanks. Kinda odd that freebsd-current doesn't have a manual > page, but FreeBSD-12 does. > That manpage you found online is in section 4x. It probably gets installed along with the xf86-input-evdev package. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
> On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote: > > > > > > On 2019-Feb-17, at 10:03, Steve Kargl > > wrote: > > > > Anyone have insight into what evdev is? There appears to > > be no manual page. When I reboot a system with custom > > kernel, the system is autoloading evdev.ko, uhid.ko, and > > wmt.ko. I do not need nor what these modules loaded. > > How does one prevent this autoloading? > > > > Looking via the web lead to: ^^^ web lies > > > > https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html > > So: > > > > NAME > >evdev - Generic Linux input driver > > > > DESCRIPTION > > > > evdev is an Xorg input driver for Linux's generic event devices. It > > therefore supports all input devices that the kernel knows about, > > including most mice, keyboards, tablets and touchscreens. evdev > > is the default driver on the major Linux distributions. > > . . . > > > > > > > > but it seems to not have a 13-current entry. It does have > > a 12.0-RELEASE entry. > > > > Thanks. Kinda odd that freebsd-current doesn't have a manual > page, but FreeBSD-12 does. rgrimes@t400:~ % man evdev No manual entry for evdev rgrimes@t400:~ % man -k evdev apropos: nothing appropriate rgrimes@t400:~ % uname -a FreeBSD t400.dnsmgr.net 12.0-RELEASE FreeBSD 12.0-RELEASE GENERIC amd64 rgrimes@t400:~ % There is no man page for evdev in 12.0-RELEASE > > I have a wireless logitech mouse. It seems that the > wireless USB dongle is causing the load of the modules. > I still understand why as ums(4) does not should a > dependency on uhid, wmt, or evdev. > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On Sun, Feb 17, 2019 at 03:04:41PM -0800, Mark Millard wrote: > > > On 2019-Feb-17, at 10:03, Steve Kargl > wrote: > > Anyone have insight into what evdev is? There appears to > be no manual page. When I reboot a system with custom > kernel, the system is autoloading evdev.ko, uhid.ko, and > wmt.ko. I do not need nor what these modules loaded. > How does one prevent this autoloading? > > Looking via the web lead to: > > https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html > So: > > NAME >evdev - Generic Linux input driver > > DESCRIPTION > > evdev is an Xorg input driver for Linux's generic event devices. It > therefore supports all input devices that the kernel knows about, > including most mice, keyboards, tablets and touchscreens. evdev > is the default driver on the major Linux distributions. > . . . > > > > but it seems to not have a 13-current entry. It does have > a 12.0-RELEASE entry. > Thanks. Kinda odd that freebsd-current doesn't have a manual page, but FreeBSD-12 does. I have a wireless logitech mouse. It seems that the wireless USB dongle is causing the load of the modules. I still understand why as ums(4) does not should a dependency on uhid, wmt, or evdev. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2019-02-17 21:03, Steve Kargl wrote: Anyone have insight into what evdev is? There appears to be no manual page. When I reboot a system with custom kernel, the system is autoloading evdev.ko, uhid.ko, and wmt.ko. I do not need nor what these modules loaded. How does one prevent this autoloading? Anyone have insight into what evdev is? evdev.ko is a small in-kernel library that makes all your input events like keyboard presses libinput-compatible. I do not need nor what these modules loaded. I think removing "option EVDEV_SUPPORT" from your kernel config should disable most of evdev.ko dependencies -- WBR Vladimir Kondratyev ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What is evdev and autoloading?
On 2019-Feb-17, at 10:03, Steve Kargl wrote: Anyone have insight into what evdev is? There appears to be no manual page. When I reboot a system with custom kernel, the system is autoloading evdev.ko, uhid.ko, and wmt.ko. I do not need nor what these modules loaded. How does one prevent this autoloading? Looking via the web lead to: https://www.freebsd.org/cgi/man.cgi?query=evdev=0=4=FreeBSD+12.0-RELEASE=default=html So: NAME evdev - Generic Linux input driver SYNOPSIS Section "InputDevice" Identifier "devname" Driver "evdev" Option "Device" "devpath" Option "Emulate3Buttons" "True" Option "Emulate3Timeout" "50" Option "GrabDevice" "False" ... EndSection DESCRIPTION evdev is an Xorg input driver for Linux's generic event devices. It therefore supports all input devices that the kernel knows about, including most mice, keyboards, tablets and touchscreens. evdev is the default driver on the major Linux distributions. . . . but it seems to not have a 13-current entry. It does have a 12.0-RELEASE entry. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
What is evdev and autoloading?
Anyone have insight into what evdev is? There appears to be no manual page. When I reboot a system with custom kernel, the system is autoloading evdev.ko, uhid.ko, and wmt.ko. I do not need nor what these modules loaded. How does one prevent this autoloading? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
