From owner-freebsd-x11@freebsd.org Sun May 20 19:28:32 2018 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DA30EED51D for ; Sun, 20 May 2018 19:28:32 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2D21F6D0B6 for ; Sun, 20 May 2018 19:28:32 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id E4CC8EED51B; Sun, 20 May 2018 19:28:31 +0000 (UTC) Delivered-To: x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF2DEED519 for ; Sun, 20 May 2018 19:28:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [176.58.89.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58BAA6D0B4 for ; Sun, 20 May 2018 19:28:31 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 40psQP1W1SzDhTS; Sun, 20 May 2018 19:28:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([IPv6:::1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [IPv6:::1]) (amavisd-new, port 10587) with ESMTPS id YsMiPNDQ74St; Sun, 20 May 2018 19:28:27 +0000 (UTC) Received: from celes.daemonic.se (celes.daemonic.se [IPv6:2001:470:dca9:2::3]) by mail.daemonic.se (Postfix) with ESMTPSA id 40psQM5fNyzDhBg; Sun, 20 May 2018 19:28:27 +0000 (UTC) Subject: Re: your mail To: Emil Velikov Cc: x11@freebsd.org References: <20170222120828.zkrfh56swen7r44o@ivaldir.etoilebsd.net> <3635692.Vys3mgEcQY@workstation.reztek> <237b2552-c97c-fd41-5509-ed611f0103dd@freebsd.org> From: Niclas Zeising Message-ID: Date: Sun, 20 May 2018 21:28:27 +0200 User-Agent: Mutt/1.5.21 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2018 19:28:32 -0000 Hi! On 05/16/18 14:57, Emil Velikov wrote: > Hi Niclas, > > On 15 May 2018 at 09:07, Niclas Zeising wrote: >> On 05/15/18 00:47, Emil Velikov wrote: >>> >>> On 22 February 2017 at 14:46, Matthew Rezny 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