your mail

Wed May 16 10:13:22 UTC 2018

On Wed, May 16, 2018 at 10:48 AM, blubee blubeeme <gurenchan at gmail.com>
wrote:

>
>
> On Wed, May 16, 2018 at 5:34 PM, Johannes Lundberg <johalun0 at gmail.com>
> wrote:
>
>>
>>
>> On Wed, May 16, 2018 at 9:58 AM, blubee blubeeme <gurenchan at gmail.com>
>> wrote:
>>
>>> On Tue, May 15, 2018 at 9:52 PM, Niclas Zeising <zeising at freebsd.org>
>>> wrote:
>>>
>>> > On 05/15/18 15:04, blubee blubeeme wrote:
>>> >
>>> >> On Tue, May 15, 2018 at 4:07 PM, Niclas Zeising <zeising at freebsd.org>
>>> >> wrote:
>>> >>
>>> >> On 05/15/18 00:47, Emil Velikov wrote:
>>> >>>
>>> >>> On 22 February 2017 at 14:46, Matthew Rezny <rezny at freebsd.org>
>>> wrote:
>>> >>>>
>>> >>>> It has been my intent to upstream as much as possible, but I was
>>> trying
>>> >>>>
>>> >>>>> to get
>>> >>>>> us caught up to current before doing so.
>>> >>>>>
>>> >>>>>
>>> >>>> Any idea what happened to this?
>>> >>>>
>>> >>>> Earlier I joined the #freebsd-xorg channel, yet it seems fairly
>>> >>>> inactive.
>>> >>>> Repeating some of my questions here, hope anyone can shed some
>>> light:
>>> >>>>
>>> >>>>    - How does FreeBSD handle loading of kernel DRM/GPU modules?
>>> >>>> Is there a daemon of sorts, manually or via hacking the graphics
>>> stack
>>> >>>> - Xorg/xf86-video*/etc
>>> >>>>
>>> >>>>    - ^^ creating /dev nodes
>>> >>>>
>>> >>>>    - How capable is your sysfs compat? Or more importantly how
>>> frowned
>>> >>>> upon it is to use it on FreeBSD?
>>> >>>>
>>> >>>> And an extra one:
>>> >>>> - How does one contribute patches to (say the graphics -
>>> >>>> libdrm/mesa/etc)
>>> >>>> ports?
>>> >>>> Is there some instructions and CI there I can throw some patches at?
>>> >>>>
>>> >>>>
>>> >>>> Hi!
>>> >>> Thank you for your mail and thanks for reaching out!  I was one of
>>> the
>>> >>> ones responding on IRC, unfortunately you caught me at a bad time
>>> here,
>>> >>> hence my suggestion to send an e-mail.
>>> >>>
>>> >>> I know the FreeBSD graphcis effort have been somewhat dormant (yeah,
>>> >>> that's an understatement), but I'm working on getting it going again
>>> >>> with a
>>> >>> group of people.  It's still in the early stages but hopefully
>>> something
>>> >>> will come out of it.  We had such a team about 4 or 5 years back, but
>>> >>> people, including myself, got different priorities (you know, life
>>> >>> happens).
>>> >>>
>>> >>> Currently, we have a working area and development repos on gitub,
>>> which
>>> >>> you can find here https://github.com/FreeBSDDesktop/, amongst other
>>> >>> things there's a fork of the FreeBSD ports repo there where most
>>> ports
>>> >>> development happens.  There's no problem getting you access to that
>>> one,
>>> >>> and we can also add forks of upstream mesa and drm repos and so on.
>>> We
>>> >>> also have a gitter chat that we're trying out.  It can be found here:
>>> >>> https://gitter.im/FreeBSDDesktop/Lobby, you're welcome to join
>>> there as
>>> >>> well.  It's connected to github.  The IRC channel #freebsd-xorg is
>>> >>> unfortunately somewhat dormant, because not everyone hangs out
>>> there, but
>>> >>> I'm available there as well.
>>> >>>
>>> >>> As I said, we're still early in the process, so all details aren't
>>> 100%
>>> >>> set yet, but this is what we have going for now.
>>> >>>
>>> >>> Now, to your questions.  As far as I know, there's no automatic
>>> loading
>>> >>> of
>>> >>> the graphics modules, apart from the really old stuff.  If memory
>>> serves
>>> >>> me
>>> >>> correctly.  The current way of doing it is to load the module before
>>> >>> starting X, usually as part of the boot process.  There might be a
>>> hack
>>> >>> in
>>> >>> xf86-video-intel to load some modules, but not the latest kms
>>> graphics
>>> >>> modules.
>>> >>>
>>> >>> Creating /dev nodes is handled automatically by devfs and devd.  I
>>> don't
>>> >>> know how it's done in detail, but it's automatic as far as at least
>>> I'm
>>> >>> concerned.
>>> >>>
>>> >>> As for sysfs, mmacy gave a good responce on IRC.
>>> >>>
>>> >>> For patches and contributing, as I said, we're trying to set up shop
>>> on
>>> >>> github (and from there merge into FreeBSD SVN repos).  The kernel
>>> bits
>>> >>> (what's called drm-next sometimes) are already there, and I've
>>> started
>>> >>> working on a ports repo there as well.  That's probably the best
>>> place to
>>> >>> start.  We don't have a CI setup currently, I use the package
>>> building
>>> >>> system poudriere locally on my desktop.  I can help you get started
>>> with
>>> >>> both poudriere and the FreeBSD ports system, and I can also help with
>>> >>> adding patches to the ports and build packages for testing.
>>> >>> I hope to be able to add more automatic building and some sort of CI
>>> >>> solution in the future, but this is where we're at today.
>>> >>>
>>> >>> We already have some local patches, they should be upstreamed, but I
>>> >>> haven't had time to work through them, and since I don't know
>>> exactly how
>>> >>> they work, it will take some time to get them upstream.
>>> >>> Can I contact you directly to get them upstreamed once they're ready?
>>> >>>
>>> >>> Once again, thank you very much for reaching out, and thank you for
>>> >>> reading to the end!
>>> >>> Regards
>>> >>> --
>>> >>> Niclas Zeising
>>> >>> FreeBSD graphics team
>>> >>>
>>> >>> I like the goals of this project better than drm-kmod stuff.
>>> >>
>>> >> You guys can always drop me a line whenever if u have a custom mailing
>>> >> list
>>> >> I'd like to stay informed on your progress.
>>> >>
>>> >> I will be looking to devote some resources to this issue in due time.
>>> >>
>>> >>
>>> > Hi!
>>> > drm-kmod is part of this.  I've mostly talked about the ports side,
>>> > because that's mostly where I work, but the kernel side is part of the
>>> same
>>> > project, so to speak.
>>> >
>>> > We will probably not have a different mailing list, but use this one as
>>> > needed.  We'll also use github and gitter.
>>> >
>>> > What is it that you don't like about drm-kmod?
>>> > Regards!
>>> > --
>>> > Niclas Zeising
>>> >
>>> > _______________________________________________
>>> > freebsd-x11 at freebsd.org mailing list
>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>> > To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>>> >
>>> Thanks for the clarification.
>>>
>>> I think that something so integral to FreeBSD can't be a patchwork of
>>> duct-tape and bubblegum.
>>>
>>
>> You're pissing on people who are working their ass off to provide good
>> and modern graphics support for FreeBSD.
>> If you can get Intel and AMD to port their drivers to FreeBSD or find the
>> manpower to maintain our own driver, sure we would be extremely grateful.
>> At least I would get 10+ hours more spare time every week.
>>
>> Also, LinuxKPI not only supports up to date graphics drivers but also
>> network drivers (which are used by large companies in production) and is
>> definitely not a patchwork.
>> LinuxKPI enables use of devices otherwise only support by Linux with
>> minimal porting effort. I'm sure you can see that this is for the good of
>> FreeBSD as a whole.
>>
>>
>>
>>>
>>> Best,
>>> Owen
>>> _______________________________________________
>>> freebsd-x11 at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
>>> To unsubscribe, send any mail to "freebsd-x11-unsubscribe at freebsd.org"
>>>
>>
>> Johannes you do great work but you missed my point.
>
> There's absolutely no reason for anyone to invest any resources into
> developing a proper graphics stack for FreeBSD if the FreeBSD devs are only
> going to rely on Jerry-rigged stuff from Linux.
>
> The mailing list is bombarded by regressions and issues with the Linuxkpi
> stuff. For lightweight stuff sure, use the Linuxkpi if u have to but for a
> major component of the platform, that's just pathetic.
>
> There are talented devs out there who can get the work done, they just
> need to be financing, then organized.
>
> Seeing as most other platforms got their networking stack from BSD, it's a
> sad state when FreeBSD has to use Linuxkpi to get networking drivers.
>
> If stating that the FreeBSD graphics stack is in a sad position is
> "shitting on people" then I'm guilty of that.
>
> I just know that we can and should do better.
>
> As far as your 10+ hours per week, I see you working on Wayland stuff, how
> much of your work is actively developing and upstreaming FreeBSD code vs
> fiddling around with Linuxkpi issues?
>
> Unless the *BSD start upstreaming code, the *BSD will just continue to sit
> in a quagmire or just another Linux distro.
>

Even if we had the resources, keeping multiple versions of massive drivers
like AMD and Intel DRM drivers is insane, especially considering how fast
the hardware is evolving.
One other possibility would be to create a Common Kernel Programming
Interface for device drivers that would allow devices manufactures to write
one driver for all Linux and *BSDs.

However, this is a lot more tricky when you're in the kernel compared to
userland.

>
> Best,
> Owen
>