your mail

[Niclas Zeising]

Hi!

On 05/16/18 14:57, Emil Velikov wrote:
> Hi Niclas,
> 
> On 15 May 2018 at 09:07, 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).
>>
> Glad to hear there's plans on reviving it.
> 
>> 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.
> Since I'm not using/testing FreeBSD I'm looking for someone to review
> any patches ;-)
> Having commit access is not really required on my end.

I don't know the internals of mesa or libdrm, but I can try to have a 
look and to test patches as need.  You can also send them to the list 
for others to try out.
I think we will find something that works, but it might take some time 
to get it worked out.

> 
> 
>>   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.
>>
> Ack. Will do in a moment.
> 
> 
>> 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.
>>
> To load the module, currently there are hacks in
> xf86-video-{intel,ati,amdgpu} and perhaps others.
> See my patch removing one [1], there extra reasoning in the thread and
> complete silence from the FreeBSD author ;-(
> 
> [1] https://lists.freedesktop.org/archives/amd-gfx/2018-April/020935.html

I will have a look and get back to you.

> 
>> 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.
>>
> Ack. On Linux the same daemon (udevd in our case) loads the kernel
> module also creates the node.
> Has there been attempts/discussions about doing the same in FreeBSD?

I don't think so.  There is some work done in general to load modules as 
needed, but I don't think anything's been done specifically for graphics.
On linux, when is the module loaded?  On start or when starting X or 
some other time?
> 
> 
>> As for sysfs, mmacy gave a good responce on IRC.
>>
> Are you sure it wasn't on gitter? You're the only person who wrote in
> the IRC channel since I joined.
> Can you please copy it here or share a link?

I think you were offline and missed the response.  Here it is:
< mmacy> sysfs compat is mediocre
< mmacy> patches welcome
< mmacy> dev nodes are created dynamically on load
< mmacy> X11 can load modules on demand, but won't for drm-next - I 
forget why
< mmacy> you can look at my lindebugfs work to see how to extend sysfs

drm-next is a port of updated graphics drivers for Intel and AMD cards, 
from the Linux drivers.

> 
> 
>> 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.
>>
> Future looks good, fingers crossed it shouldn't take too long to reach.

Yeah, I hope so.  I just wish I had more time, but don't we all? :)

> 
>> 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?
>>
> In general I'd recommend two things:
>   - send patches upstream _alongside_ the FreeBSD submission
> Either the submitter or reviewer can do that. You want that to avoid
> redoing the same work multiple times.
>   - contact the project itself, not individuals
> You can CC individuals, but having only one person is back since the
> review comments may be partial or outright wrong.
> 

I hope to be able to do this.  I will probably ask more questions 
regarding the process for submitting patches once I get there.

>> Once again, thank you very much for reaching out, and thank you for reading
>> to the end!
> 
> Thanks for taking the time to right this. I'll see about opening a PR
> or two on FreeBSDDesktop.
> Fingers crossed it will flow smoothly and get into the official repos quickly.

I hope so to.  It will take a little time to get the ball rolling, but 
it's a start.  I hope we can keep in touch as things progress, either 
here or on gitter.

Once again, huge thanks for reaching out!
Regards
-- 
Niclas Zeising