Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 12:18:47PM -0500, Jason Ekstrand wrote: > On Tue, Mar 17, 2020 at 12:13 PM Jacob Lifshay > wrote: > > > > One related issue with explicit sync using sync_file is that combined > > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the > > rendering in userspace (like llvmpipe but for Vulkan and with extra > > instructions for GPU tasks) but need to synchronize with other > > drivers/processes is that there should be some way to create an > > explicit fence/semaphore from userspace and later signal it. This > > seems to conflict with the requirement for a sync_file to complete in > > finite time, since the user process could be stopped or killed. > > Yeah... That's going to be a problem. The only way I could see that > working is if you created a sync_file that had a timeout associated > with it. However, then you run into the issue where you may have > corruption if stuff doesn't complete on time. Then again, you're not > really dealing with an external unit and so the latency cost of going > across the window system protocol probably isn't massively different > from the latency cost of triggering the sync_file. Maybe the answer > there is to just do everything in-order and not worry about > synchronization? vgem does that already (fences with timeout). The corruption issue is also not new, if your shaders take forever real gpus will nick your rendering with a quick reset. Iirc someone (from cros google team maybe) was even looking into making llvmpipe run on top of vgem as a real dri/drm mesa driver. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 11:01:57AM +0100, Michel Dänzer wrote: > On 2020-03-16 7:33 p.m., Marek Olšák wrote: > > On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote: > >> On 2020-03-16 4:50 a.m., Marek Olšák wrote: > >>> The synchronization works because the Mesa driver waits for idle (drains > >>> the GFX pipeline) at the end of command buffers and there is only 1 > >>> graphics queue, so everything is ordered. > >>> > >>> The GFX pipeline runs asynchronously to the command buffer, meaning the > >>> command buffer only starts draws and doesn't wait for completion. If the > >>> Mesa driver didn't wait at the end of the command buffer, the command > >>> buffer would finish and a different process could start execution of its > >>> own command buffer while shaders of the previous process are still > >> running. > >>> > >>> If the Mesa driver submits a command buffer internally (because it's > >> full), > >>> it doesn't wait, so the GFX pipeline doesn't notice that a command buffer > >>> ended and a new one started. > >>> > >>> The waiting at the end of command buffers happens only when the flush is > >>> external (Swap buffers, glFlush). > >>> > >>> It's a performance problem, because the GFX queue is blocked until the > >> GFX > >>> pipeline is drained at the end of every frame at least. > >>> > >>> So explicit fences for SwapBuffers would help. > >> > >> Not sure what difference it would make, since the same thing needs to be > >> done for explicit fences as well, doesn't it? > > > > No. Explicit fences don't require userspace to wait for idle in the command > > buffer. Fences are signalled when the last draw is complete and caches are > > flushed. Before that happens, any command buffer that is not dependent on > > the fence can start execution. There is never a need for the GPU to be idle > > if there is enough independent work to do. > > I don't think explicit fences in the context of this discussion imply > using that different fence signalling mechanism though. My understanding > is that the API proposed by Jason allows implicit fences to be used as > explicit ones and vice versa, so presumably they have to use the same > signalling mechanism. > > > Anyway, maybe the different fence signalling mechanism you describe > could be used by the amdgpu kernel driver in general, then Mesa could > drop the waits for idle and get the benefits with implicit sync as well? Yeah, this is entirely about the programming model visible to userspace. There shouldn't be any impact on the driver's choice of a top vs. bottom of the gpu pipeline used for synchronization, that's entirely up to what you're hw/driver/scheduler can pull off. Doing a full gfx pipeline flush for shared buffers, when your hw can do be, sounds like an issue to me that's not related to this here at all. It might be intertwined with amdgpu's special interpretation of dma_resv fences though, no idea. We might need to revamp all that. But for a userspace client that does nothing fancy (no multiple render buffer targets in one bo, or vk style "I write to everything all the time, perhaps" stuff) there should be 0 perf difference between implicit sync through dma_resv and explicit sync through sync_file/syncobj/dma_fence directly. If there is I'd consider that a bit a driver bug. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem
On Wed, Mar 18, 2020 at 11:05:48AM +0100, Michel Dänzer wrote: > On 2020-03-17 6:21 p.m., Lucas Stach wrote: > > That's one of the issues with implicit sync that explicit may solve: > > a single client taking way too much time to render something can > > block the whole pipeline up until the display flip. With explicit > > sync the compositor can just decide to use the last client buffer if > > the latest buffer isn't ready by some deadline. > > FWIW, the compositor can do this with implicit sync as well, by polling > a dma-buf fd for the buffer. (Currently, it has to poll for writable, > because waiting for the exclusive fence only isn't enough with amdgpu) Would be great if we don't have to make this recommended uapi, just because amdgpu leaks it's trickery into the wider world. Polling for read really should be enough (and I guess Christian gets to fix up amdgpu more, at least for anything that has a dma-buf attached even if it's not shared with anything !amdgpu.ko). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Plumbing explicit synchronization through the Linux ecosystem
On Tue, Mar 17, 2020 at 11:27:28AM -0500, Jason Ekstrand wrote: > On Tue, Mar 17, 2020 at 10:33 AM Nicolas Dufresne > wrote: > > > > Le lundi 16 mars 2020 à 23:15 +0200, Laurent Pinchart a écrit : > > > Hi Jason, > > > > > > On Mon, Mar 16, 2020 at 10:06:07AM -0500, Jason Ekstrand wrote: > > > > On Mon, Mar 16, 2020 at 5:20 AM Laurent Pinchart wrote: > > > > > Another issue is that V4L2 doesn't offer any guarantee on job > > > > > ordering. > > > > > When you queue multiple buffers for camera capture for instance, you > > > > > don't know until capture complete in which buffer the frame has been > > > > > captured. > > > > > > > > Is this a Kernel UAPI issue? Surely the kernel driver knows at the > > > > start of frame capture which buffer it's getting written into. I > > > > would think that the kernel APIs could be adjusted (if we find good > > > > reason to do so!) such that they return earlier and return a (buffer, > > > > fence) pair. Am I missing something fundamental about video here? > > > > > > For cameras I believe we could do that, yes. I was pointing out the > > > issues caused by the current API. For video decoders I'll let Nicolas > > > answer the question, he's way more knowledgeable that I am on that > > > topic. > > > > Right now, there is simply no uAPI for supporting asynchronous errors > > reporting when fences are invovled. That is true for both camera's and > > CODEC. It's likely what all the attempt was missing, I don't know > > enough myself to suggest something. > > > > Now, why Stateless video decoders are special is another subject. In > > CODECs, the decoding and the presentation order may differ. For > > Stateless kind of CODEC, a bitstream is passed to the HW. We don't know > > if this bitstream is fully valid, since the it is being parsed and > > validated by the firmware. It's also firmware job to decide which > > buffer should be presented first. > > > > In most firmware interface, that information is communicated back all > > at once when the frame is ready to be presented (which may be quite > > some time after it was decoded). So indeed, a fence model is not really > > easy to add, unless the firmware was designed with that model in mind. > > Just to be clear, I think we should do whatever makes sense here and > not try to slam sync_file in when it doesn't make sense just because > we have it. The more I read on this thread, the less out-fences from > video decode sound like they make sense unless we have a really solid > plan for async error reporting. It's possible, depending on how many > processes are involved in the pipeline, that async error reporting > could help reduce latency a bit if it let the kernel report the error > directly to the last process in the chain. However, I'm not convinced > the potential for userspace programmer error is worth it.. That said, > I'm happy to leave that up to the actual video experts. (I just do 3D) dma_fence has an error state which you can set when things went south. The fence still completes (to guarantee forward progress). Currently that error code isn't really propagated anywhere (well i915 iirc does something like that since it tracks the depedencies internally in the scheduler). Definitely not at the dma_fence level, since we don't track the dependency graph there at all. We might want to add that, would at least be possible. If we track the cascading dma_fence error state in the kernel I do think this could work. I'm not sure whether it's actually a good/useful idea still. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
doing it anyway. If it > > takes me a single day to set all this up (I estimate a couple of > > weeks), that costs my employer a lot more than sponsoring the costs of > > the inefficiencies of the system that has accumulated. > > I'm not trying to knock the engineering works the CI contributors have > done at all, but I've never seen a real discussion about costs until > now. Engineers aren't accountants. > > The thing we seem to be missing here is fiscal responsibility. I know > this email is us being fiscally responsible, but it's kinda after the > fact. > > I cannot commit my employer to spending a large amount of money (> 0 > actually) without a long and lengthy process with checks and bounds. > Can you? > > The X.org board has budgets and procedures as well. I as a developer > of Mesa should not be able to commit the X.org foundation to spending > large amounts of money without checks and bounds. > > The CI infrastructure lacks any checks and bounds. There is no link > between editing .gitlab-ci/* and cashflow. There is no link to me > adding support for a new feature to llvmpipe that blows out test times > (granted it won't affect CI budget but just an example). We're working to get the logging in place to know which projects exactly burn down the money so that we can take specific actions. If needed. So pretty soon you wont be able to just burn down endless amounts of cash with a few gitlab-ci commits. Or at least not for long until we catch you and you either fix things up or CI is gone for your project. > The fact that clouds run on credit means that it's not possible to say > budget 30K and say when that runs out it runs out, you end up getting > bills for ever increasing amounts that you have to cover, with nobody > "responsible" for ever reducing those bills. Higher Faster Further > baby comes to mind. We're working on this, since it's the boards responsibility to be on top of stuff. It's simply that we didn't expect a massive growth of this scale and this quickly, so we're a bit behind on the controlling aspect. Also I guess it wasnt clear, but the board decision yesterday was the stop loss order where we cut the cord (for CI at least). So yeah the short term budget is firmly in place now. > Has X.org actually allocated the remaining cash in it's bank account > to this task previously? Was there plans for this money that can't be > executed now because we have to pay the cloud fees? If we continue to > May and the X.org bank account hits 0, can XDC happen? There's numbers elsewhere in this thread, but if you'd read the original announcement it states that the stop loss would still guarantee that we can pay for everything for at least one year. We're not going to get even close to 0 in the bank account. So yeah XDC happens, and it'll also still happen next year. Also fd.o servers will keep running. The only thing we might need to switch off is the CI support. > Budgeting and cloud is hard, the feedback loops are messy. In the old > system the feedback loop was simple, we don't have admin time or money > for servers we don't get the features, cloud allows us to get the > features and enjoy them and at some point in the future the bill gets > paid by someone else. Credit cards lifestyles all the way. Uh ... where exactly do you get the credit card approach from? SPI is legally not allowed to extend us a credit (we're not a legal org anymore), so if we hit 0 it's out real quick. No credit for us. If SPI isnt on top of that it's their loss (but they're getting pretty good at tracking stuff with the contractor they now have and all that). Which is not going to happen btw, if you've read the announcement mail and all that. Cheers, Daniel > Like maybe we can grow up here and find sponsors to cover all of this, > but it still feels a bit backwards from a fiscal pov. > > Again I'm not knocking the work people have done at all, CI is very > valuable to the projects involved, but that doesn't absolve us from > costs. > > Dave. -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund wrote: > > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter > > wrote: > > > Hi all, > > > > > > You might have read the short take in the X.org board meeting > > > minutes > > > already, here's the long version. > > > > > > The good news: gitlab.fd.o has become very popular with our > > > communities, and is used extensively. This especially includes all > > > the > > > CI integration. Modern development process and tooling, yay! > > > > > > The bad news: The cost in growth has also been tremendous, and it's > > > breaking our bank account. With reasonable estimates for continued > > > growth we're expecting hosting expenses totalling 75k USD this > > > year, > > > and 90k USD next year. With the current sponsors we've set up we > > > can't > > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > > without any of the CI features enabled would total 30k USD, which > > > is > > > within X.org's ability to support through various sponsorships, > > > mostly > > > through XDC. > > > > > > Note that X.org does no longer sponsor any CI runners themselves, > > > we've stopped that. The huge additional expenses are all just in > > > storing and serving build artifacts and images to outside CI > > > runners > > > sponsored by various companies. A related topic is that with the > > > growth in fd.o it's becoming infeasible to maintain it all on > > > volunteer admin time. X.org is therefore also looking for admin > > > sponsorship, at least medium term. > > > > > > Assuming that we want cash flow reserves for one year of > > > gitlab.fd.o > > > (without CI support) and a trimmed XDC and assuming no sponsor > > > payment > > > meanwhile, we'd have to cut CI services somewhere between May and > > > June > > > this year. The board is of course working on acquiring sponsors, > > > but > > > filling a shortfall of this magnitude is neither easy nor quick > > > work, > > > and we therefore decided to give an early warning as soon as > > > possible. > > > Any help in finding sponsors for fd.o is very much appreciated. > > > > a) Ouch. > > > > b) we probably need to take a large step back here. > > > > I kinda agree, but maybe the step doesn't have to be *too* large? > > I wonder if we could solve this by restructuring the project a bit. I'm > talking purely from a Mesa point of view here, so it might not solve > the full problem, but: > > 1. It feels silly that we need to test changes to e.g the i965 driver > on dragonboards. We only have a big "do not run CI at all" escape- > hatch. > > 2. A lot of us are working for a company that can probably pay for > their own needs in terms of CI. Perhaps moving some costs "up front" to > the company that needs it can make the future of CI for those who can't > do this > > 3. I think we need a much more detailed break-down of the cost to make > educated changes. For instance, how expensive is Docker image > uploads/downloads (e.g intermediary artifacts) compared to build logs > and final test-results? What kind of artifacts? We have logs somewhere, but no one yet got around to analyzing that. Which will be quite a bit of work to do since the cloud storage is totally disconnected from the gitlab front-end, making the connection to which project or CI job caused something is going to require scripting. Volunteers definitely very much welcome I think. > One suggestion would be to do something more similar to what the kernel > does, and separate into different repos for different subsystems. This > could allow us to have separate testing-pipelines for these repos, > which would mean that for instance a change to RADV didn't trigger a > full Panfrost test-run. Uh as someone who lives the kernel multi-tree model daily, there's a _lot_ of pain involved. I think much better to look at filtering out CI targets for when nothing relevant happened. But that gets somewhat tricky, since "nothing relevant" is always only relative to some baseline, so bit of scripting and all involved to make sure you don't run stuff too often or (probably worse) not often enough. -Daniel > This would probably require us to accept using a more branch-heavy > work-flow. I don't personally think that would be a bad thing. > > But this is all kinda based on an assumption that running hardware- > testing is the expensive
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 4:38 AM Dave Airlie wrote: > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter wrote: > > > > Hi all, > > > > You might have read the short take in the X.org board meeting minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular with our > > communities, and is used extensively. This especially includes all the > > CI integration. Modern development process and tooling, yay! > > > > The bad news: The cost in growth has also been tremendous, and it's > > breaking our bank account. With reasonable estimates for continued > > growth we're expecting hosting expenses totalling 75k USD this year, > > and 90k USD next year. With the current sponsors we've set up we can't > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > without any of the CI features enabled would total 30k USD, which is > > within X.org's ability to support through various sponsorships, mostly > > through XDC. > > > > Note that X.org does no longer sponsor any CI runners themselves, > > we've stopped that. The huge additional expenses are all just in > > storing and serving build artifacts and images to outside CI runners > > sponsored by various companies. A related topic is that with the > > growth in fd.o it's becoming infeasible to maintain it all on > > volunteer admin time. X.org is therefore also looking for admin > > sponsorship, at least medium term. > > > > Assuming that we want cash flow reserves for one year of gitlab.fd.o > > (without CI support) and a trimmed XDC and assuming no sponsor payment > > meanwhile, we'd have to cut CI services somewhere between May and June > > this year. The board is of course working on acquiring sponsors, but > > filling a shortfall of this magnitude is neither easy nor quick work, > > and we therefore decided to give an early warning as soon as possible. > > Any help in finding sponsors for fd.o is very much appreciated. > > a) Ouch. > > b) we probably need to take a large step back here. > > Look at this from a sponsor POV, why would I give X.org/fd.o > sponsorship money that they are just giving straight to google to pay > for hosting credits? Google are profiting in some minor way from these > hosting credits being bought by us, and I assume we aren't getting any > sort of discounts here. Having google sponsor the credits costs google > substantially less than having any other company give us money to do > it. > > If our current CI architecture is going to burn this amount of money a > year and we hadn't worked this out in advance of deploying it then I > suggest the system should be taken offline until we work out what a > sustainable system would look like within the budget we have, whether > that be never transferring containers and build artifacts from the > google network, just having local runner/build combos etc. Google has sponsored 30k in hosting credits last year, these simply ran out _much_ faster than anyone planned for. So this is by far not a free thing for them. Plus there's also other companies sponsoring CI runners and what not else in equally substantial amounts, plus the biggest thing, sponsored admin time (more or less officially). So there's a _lot_ of room for companies like Red Hat to sponsor without throwing any money in google's revenue stream. Or it doesn't happen, and then yeah the decision has already been made to shutter the CI services. So this is also a question of whether we (as a community and all the companies benefitting from the work done) really want this, or maybe not quite. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 2:54 AM Carsten Haitzler wrote: > > On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter > said: > > Might I suggest that given the kind of expenses detailed here, literally > buying > 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be incredibly > cheaper? (we (enlightenment.org) have been doing so for years on a single > box). We farm out CI to travis via gihub mirrors as it's not considered > an essential core service (unlike mailing lists, git, phabricator whch nwe > still run - we can live without CI for a while and find other ways). > > The cost is the odd HDD replacement every few years and maybe every 10y or so > a > new box. That's a massively lower cost than you are quoting below. > > OSUOSL provide bandwidth, power, rack space etc. for free. They have been > fantastic IMHO and the whole "no fat bills" is awesome and you get a full > system to set up any way you like. You just bring the box. That should drop > cost > through the floor. It will require some setup and admin though. We've moved away from this setup (all other fd.o services run like this) because in a volunteer run org with volunteer admins, admin time is a premium. So if we'd go the physical boxes route we could indeed cut a lot of hosting costs. But we'd need to get a paid admin from somewhere to keep the lights on. Aside from the money needed this has the problem that X.org has zero experience with contractors, and SPI as our fiscal sponsor also only just started with one part time contractor. -Daniel > > Hi all, > > > > You might have read the short take in the X.org board meeting minutes > > already, here's the long version. > > > > The good news: gitlab.fd.o has become very popular with our > > communities, and is used extensively. This especially includes all the > > CI integration. Modern development process and tooling, yay! > > > > The bad news: The cost in growth has also been tremendous, and it's > > breaking our bank account. With reasonable estimates for continued > > growth we're expecting hosting expenses totalling 75k USD this year, > > and 90k USD next year. With the current sponsors we've set up we can't > > sustain that. We estimate that hosting expenses for gitlab.fd.o > > without any of the CI features enabled would total 30k USD, which is > > within X.org's ability to support through various sponsorships, mostly > > through XDC. > > > > Note that X.org does no longer sponsor any CI runners themselves, > > we've stopped that. The huge additional expenses are all just in > > storing and serving build artifacts and images to outside CI runners > > sponsored by various companies. A related topic is that with the > > growth in fd.o it's becoming infeasible to maintain it all on > > volunteer admin time. X.org is therefore also looking for admin > > sponsorship, at least medium term. > > > > Assuming that we want cash flow reserves for one year of gitlab.fd.o > > (without CI support) and a trimmed XDC and assuming no sponsor payment > > meanwhile, we'd have to cut CI services somewhere between May and June > > this year. The board is of course working on acquiring sponsors, but > > filling a shortfall of this magnitude is neither easy nor quick work, > > and we therefore decided to give an early warning as soon as possible. > > Any help in finding sponsors for fd.o is very much appreciated. > > > > Thanks, Daniel > > -- > > Daniel Vetter > > Software Engineer, Intel Corporation > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > _______ > > xorg-devel@lists.x.org: X.Org development > > Archives: http://lists.x.org/archives/xorg-devel > > Info: https://lists.x.org/mailman/listinfo/xorg-devel > > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - ras...@rasterman.com > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
gitlab.fd.o financial situation and impact on services
Hi all, You might have read the short take in the X.org board meeting minutes already, here's the long version. The good news: gitlab.fd.o has become very popular with our communities, and is used extensively. This especially includes all the CI integration. Modern development process and tooling, yay! The bad news: The cost in growth has also been tremendous, and it's breaking our bank account. With reasonable estimates for continued growth we're expecting hosting expenses totalling 75k USD this year, and 90k USD next year. With the current sponsors we've set up we can't sustain that. We estimate that hosting expenses for gitlab.fd.o without any of the CI features enabled would total 30k USD, which is within X.org's ability to support through various sponsorships, mostly through XDC. Note that X.org does no longer sponsor any CI runners themselves, we've stopped that. The huge additional expenses are all just in storing and serving build artifacts and images to outside CI runners sponsored by various companies. A related topic is that with the growth in fd.o it's becoming infeasible to maintain it all on volunteer admin time. X.org is therefore also looking for admin sponsorship, at least medium term. Assuming that we want cash flow reserves for one year of gitlab.fd.o (without CI support) and a trimmed XDC and assuming no sponsor payment meanwhile, we'd have to cut CI services somewhere between May and June this year. The board is of course working on acquiring sponsors, but filling a shortfall of this magnitude is neither easy nor quick work, and we therefore decided to give an early warning as soon as possible. Any help in finding sponsors for fd.o is very much appreciated. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Requests for Proposal for hosting XDC 2020
Hi all, The X.org board is soliciting proposals to host XDC in 2020. By the usual rotation a location in Europe is preferred, but the board will also consider other locations, especially if there's an interesting co-location with another conference. If you consider hosting XDC, we have assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ Due to interest by a few groups to host XDC 2020 we decided to slightly accelerate the RFP schedule, to be able to give a final answers to the teams who've already submitted early draft proposals. Please submit your proposal with at least the key information about location, possible dates and estimated costs to bo...@foundation.x.org latest by 30th June 2019. An early quick heads-up to the board if you consider hosting would also be good, in case we need to adjust the schedule a bit. Also earlier is better since in general there will be a bit of Q with organizers. The board plans to make a final decision by end of July. If you just have some questions about what organizing XDC entails, please feel free to chat with a previous organizers, or with someone from the board. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote: > On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: > >> > >> Hi, > >> > >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: > >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: > >>>> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > >>>>> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone > >>>>> wrote: > >>>>>> Yeah, I think it makes sense. Some things we do: > >>>>>> - provide hosted network services for collaborative development, > >>>>>> testing, and discussion, of open-source projects > >>>>>> - administer, improve, and extend this suite of services as necessary > >>>>>> - assist open-source projects in their use of these services > >>>>>> - purchase, lease, or subscribe to, computing and networking > >>>>>> infrastructure allowing these services to be run > >>>>> > >>>>> I fully agree that we should document all this. I don't think the > >>>>> bylaws are the right place though, much better to put that into > >>>>> policies that the board approves and which can be adapted as needed. > >>>>> Imo bylaws should cover the high-level mission and procedural details, > >>>>> as our "constitution", with the really high acceptance criteria of > >>>>> 2/3rd of all members approving any changes. Some of the early > >>>>> discussions tried to spell out a lot of the fd.o policies in bylaw > >>>>> changes, but then we realized it's all there already. All the details > >>>>> are much better served in policies enacted by the board, like we do > >>>>> with everything else. > >>>>> > >>>>> As an example, let's look at XDC. Definitely one of the biggest things > >>>>> the foundation does, with handling finances, travel sponsoring grants, > >>>>> papers committee, and acquiring lots of sponsors. None of this is > >>>>> spelled out in the bylaws, it's all in policies that the board > >>>>> deliberates and approves. I think this same approach will also work > >>>>> well for fd.o. > >>>>> > >>>>> And if members are unhappy with what the board does, they can fix in > >>>>> the next election by throwing out the unwanted directors. > >>>> > >>>> yeah, fair call. though IMO in that case we can just reduce to > >>>> > >>>>\item Support free and open source projects through the > >>>> freedesktop.org > >>>>infrastructure. > >>>> > >>>> because my gripe is less with the fdo bit but more with defining what > >>>> "project hosting" means, given that we use that term to exclude fdo > >>>> projects > >>>> from getting anything else. I think just dropping that bit is sufficient. > >>> > >>> Hm yeah, through the lens of "everything not explicitly listed isn't in > >>> scope as X.org's purpose", leaving this out is probably clearest. And > >>> under 2.4 (i) the board already has the duty to interpret what exactly > >>> this means wrt membership eligibility. > >>> > >>> Harry, Daniel, what do you think? > >> > >> Yeah, that's fine. I didn't specifically want the enumerated list of > >> what we do in the bylaws, just spelling it out for background as a > >> handy reference I could point to later. I think maybe we could reduce > >> it to something like: > >> Administer, support, and improve the freedesktop.org hosting > >> infrastructure to support the projects it hosts > > > > This feels a bit self-referential, not the best for the purpose of > > what X.org does. If we do want to be a bit more specific we could do > > something like with (i) and provide a list that the board can extend: > > > > \item Support free and open source projects through the freedesktop.org > > infrastructure. This includes, but is not limited to: > > Administering and providing > > project hosting services. > > > > I like this phrasing, but won't that bring us back to David Hutterer's > point about defining what "project hosting services" mean
Re: [RFC] Allow fd.o to join forces with X.Org
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
> > > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > > + \item Support free and open source projects through the
> > > > > freedesktop.org
> > > > > + infrastructure. For projects outside the scope of item
> > > > > (\ref{1}) support
> > > > > + extends to project hosting only.
> > > > > +
> > > >
> > > > Yes to the idea but given that the remaining 11 pages cover all the
> > > > legalese
> > > > for xorg I think we need to add at least a section of what "project
> > > > hosting"
> > > > means. Even if it's just a "includes but is not limited to blah". And
> > > > some
> > > > addition to 4.1 Powers is needed to spell out what the BoD can do in
> > > > regards
> > > > to fdo.
> > >
> > > Yeah, I think it makes sense. Some things we do:
> > > - provide hosted network services for collaborative development,
> > > testing, and discussion, of open-source projects
> > > - administer, improve, and extend this suite of services as necessary
> > > - assist open-source projects in their use of these services
> > > - purchase, lease, or subscribe to, computing and networking
> > > infrastructure allowing these services to be run
> >
> > I fully agree that we should document all this. I don't think the
> > bylaws are the right place though, much better to put that into
> > policies that the board approves and which can be adapted as needed.
> > Imo bylaws should cover the high-level mission and procedural details,
> > as our "constitution", with the really high acceptance criteria of
> > 2/3rd of all members approving any changes. Some of the early
> > discussions tried to spell out a lot of the fd.o policies in bylaw
> > changes, but then we realized it's all there already. All the details
> > are much better served in policies enacted by the board, like we do
> > with everything else.
> >
> > As an example, let's look at XDC. Definitely one of the biggest things
> > the foundation does, with handling finances, travel sponsoring grants,
> > papers committee, and acquiring lots of sponsors. None of this is
> > spelled out in the bylaws, it's all in policies that the board
> > deliberates and approves. I think this same approach will also work
> > well for fd.o.
> >
> > And if members are unhappy with what the board does, they can fix in
> > the next election by throwing out the unwanted directors.
>
> yeah, fair call. though IMO in that case we can just reduce to
>
>\item Support free and open source projects through the freedesktop.org
>infrastructure.
>
> because my gripe is less with the fdo bit but more with defining what
> "project hosting" means, given that we use that term to exclude fdo projects
> from getting anything else. I think just dropping that bit is sufficient.
Hm yeah, through the lens of "everything not explicitly listed isn't in
scope as X.org's purpose", leaving this out is probably clearest. And
under 2.4 (i) the board already has the duty to interpret what exactly
this means wrt membership eligibility.
Harry, Daniel, what do you think?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: > > Hi, > > On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: > > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > > > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone > > > > wrote: > > > > > Yeah, I think it makes sense. Some things we do: > > > > > - provide hosted network services for collaborative development, > > > > > testing, and discussion, of open-source projects > > > > > - administer, improve, and extend this suite of services as > > > > > necessary > > > > > - assist open-source projects in their use of these services > > > > > - purchase, lease, or subscribe to, computing and networking > > > > > infrastructure allowing these services to be run > > > > > > > > I fully agree that we should document all this. I don't think the > > > > bylaws are the right place though, much better to put that into > > > > policies that the board approves and which can be adapted as needed. > > > > Imo bylaws should cover the high-level mission and procedural details, > > > > as our "constitution", with the really high acceptance criteria of > > > > 2/3rd of all members approving any changes. Some of the early > > > > discussions tried to spell out a lot of the fd.o policies in bylaw > > > > changes, but then we realized it's all there already. All the details > > > > are much better served in policies enacted by the board, like we do > > > > with everything else. > > > > > > > > As an example, let's look at XDC. Definitely one of the biggest things > > > > the foundation does, with handling finances, travel sponsoring grants, > > > > papers committee, and acquiring lots of sponsors. None of this is > > > > spelled out in the bylaws, it's all in policies that the board > > > > deliberates and approves. I think this same approach will also work > > > > well for fd.o. > > > > > > > > And if members are unhappy with what the board does, they can fix in > > > > the next election by throwing out the unwanted directors. > > > > > > yeah, fair call. though IMO in that case we can just reduce to > > > > > >\item Support free and open source projects through the freedesktop.org > > >infrastructure. > > > > > > because my gripe is less with the fdo bit but more with defining what > > > "project hosting" means, given that we use that term to exclude fdo > > > projects > > > from getting anything else. I think just dropping that bit is sufficient. > > > > Hm yeah, through the lens of "everything not explicitly listed isn't in > > scope as X.org's purpose", leaving this out is probably clearest. And > > under 2.4 (i) the board already has the duty to interpret what exactly > > this means wrt membership eligibility. > > > > Harry, Daniel, what do you think? > > Yeah, that's fine. I didn't specifically want the enumerated list of > what we do in the bylaws, just spelling it out for background as a > handy reference I could point to later. I think maybe we could reduce > it to something like: > Administer, support, and improve the freedesktop.org hosting > infrastructure to support the projects it hosts This feels a bit self-referential, not the best for the purpose of what X.org does. If we do want to be a bit more specific we could do something like with (i) and provide a list that the board can extend: \item Support free and open source projects through the freedesktop.org infrastructure. This includes, but is not limited to: Administering and providing project hosting services. That would make it clear that admins are in scope, and everything else is up to the board. Similar to how drm, mesa, wayland and X are explicitly in scope, and stuff like cros/android gfx stack or libinput is up to the board to decide/clarify. > Gives us enough scope to grow in the future (e.g. we don't need a > bylaws change to move from pure-git to GitLab), avoids the sticky > question of what exactly fd.o hosts in the bylaws (e.g. if > NetworkManager needs a new repo then we don't have to consult > membership to add it), but is still pretty firmly limited in scope. > > Any of the above have my in-principle ack though, I think they're all > reasonable colours for our lovely shed. Well, one more bikeshed from me! Cheers, Daniel > > Cheers, > Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
>
> On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > + \item Support free and open source projects through the
> > > freedesktop.org
> > > + infrastructure. For projects outside the scope of item (\ref{1})
> > > support
> > > + extends to project hosting only.
> > > +
> >
> > Yes to the idea but given that the remaining 11 pages cover all the legalese
> > for xorg I think we need to add at least a section of what "project hosting"
> > means. Even if it's just a "includes but is not limited to blah". And some
> > addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> > to fdo.
>
> Yeah, I think it makes sense. Some things we do:
> - provide hosted network services for collaborative development,
> testing, and discussion, of open-source projects
> - administer, improve, and extend this suite of services as necessary
> - assist open-source projects in their use of these services
> - purchase, lease, or subscribe to, computing and networking
> infrastructure allowing these services to be run
I fully agree that we should document all this. I don't think the
bylaws are the right place though, much better to put that into
policies that the board approves and which can be adapted as needed.
Imo bylaws should cover the high-level mission and procedural details,
as our "constitution", with the really high acceptance criteria of
2/3rd of all members approving any changes. Some of the early
discussions tried to spell out a lot of the fd.o policies in bylaw
changes, but then we realized it's all there already. All the details
are much better served in policies enacted by the board, like we do
with everything else.
As an example, let's look at XDC. Definitely one of the biggest things
the foundation does, with handling finances, travel sponsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
the next election by throwing out the unwanted directors.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
XDC 2018 feedback and comments
Hi all, Once more huge thanks to the entire team from g.p.u.l. and Igalia, personally I think this was an extremely well organized XDC! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to both the x.org board and gpul - they want to know how to improve and what to keep for the next conference they're going to organize too. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] XDC 2018: Call for Papers
Hi all, We received an overwhelming response for this CFP - 35+ proposals (and still some latecomers trickling in), for only 18 slots. What we didn't much get (and the CFP failed to make it clear that we're looking for this) is proposals for the workshop/discussion track in the 2nd room. In the past we scheduled that ad-hoc at the conference, but this year it would make sense to organize this. Especially since we expect a lot of the talks we had to reject to end up in hallway discussions. Formal workshop submissions also help us in scheduling the main track - anything that's expected to generate a lot of discussions will be put early. Right now we have 1 proposal for the workshop track. We'd like to have more. For details please look at "Workshop Track" at https://www.x.org/wiki/Events/PapersCommittee/ If you have a topic, please send your proposal to bo...@foundation.lists.org. Thanks, Daniel On Mon, Apr 2, 2018 at 12:47 PM, Samuel Iglesias Gonsálvez wrote: > Hello, > > I have the pleasure to announce that the X.org Developer Conference 2018 > will be held in A Coruña, Spain from September 26th to September 28th. > The venue is located at the Computer Science faculty of the University > of Coruña. > > This year, we have created a new website for the event: > > https://xdc2018.x.org > > And a Twitter account for announcing updates, please follow us! > > https://twitter.com/xdc2018 > > However, we are going to keep updating the good old wiki too: > > https://www.x.org/wiki/Events/XDC2018 > > As usual, we are open to talks across the layers of the graphics stack, > from the kernel to desktop environments / graphical applications and > about how to make things better for the developers who build them. Other > topics such as Virtual Reality are also welcome. If you're not sure if > something might fit, mail us or add it to the ideas list found in the > program page at: > > https://www.x.org/wiki/Events/XDC2018/Program/ > > The Call for Papers information is here: https://xdc2018.x.org/#cfp. > Remember, the deadline for submissions is Wednesday 25th July 2018 17:00 > UTC. Don't forget to send your proposals to bo...@foundation.x.org! > > The conference is free of charge and open to the general public. If you > plan on coming, please add yourself to the attendees list: > > https://www.x.org/wiki/Events/XDC2018/Attendees/ > > We'll use this list of attendees to make badges and plan for the > catering, so if you are attending please add your name as early as > possible. > > I am looking forward to seeing you there. If you have any > inquiries/questions, please send an email to xdc2...@gpul.org, adding on > CC the X.org board (bo...@foundation.x.org). > > Best regards, > > Sam > _______ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Requests for Proposal for hosting XDC 2019
On Thu, Jun 21, 2018 at 11:16 PM, Daniel Vetter wrote: > Hi all, > > The X.org board is soliciting proposals to host XDC in 2019. By the usual > rotation a location in (North) America is preferred, but the board will also > consider other locations, especially if there's an interesting co-location > with another conference. > > If you consider hosting XDC, we have assembled a wiki page with what's > generally expected and needed: > > https://www.x.org/wiki/Events/RFP/ > > If possible the board would like to decide on the next location at XDC > 2017 in Mountain View, please submit your proposal with at least the key ^^ should be XDC 2018 in La Coruna ofc. So much for not properly updating the template again this year :-) -Daniel > information about location, possible dates and estimated costs to > bo...@foundation.x.org latest by 31th August. An early quick heads-up > to the board if you consider hosting would also be good, in case we > need to adjust the schedule a bit. Also earlier is better since in > generally there > will be a bit of Q with organizers. > > And if you just have some questions about what organizing XDC entails, > please feel free to chat with a previous organizers, or with someone from > the board. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Requests for Proposal for hosting XDC 2019
Hi all, The X.org board is soliciting proposals to host XDC in 2019. By the usual rotation a location in (North) America is preferred, but the board will also consider other locations, especially if there's an interesting co-location with another conference. If you consider hosting XDC, we have assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ If possible the board would like to decide on the next location at XDC 2017 in Mountain View, please submit your proposal with at least the key information about location, possible dates and estimated costs to bo...@foundation.x.org latest by 31th August. An early quick heads-up to the board if you consider hosting would also be good, in case we need to adjust the schedule a bit. Also earlier is better since in generally there will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with a previous organizers, or with someone from the board. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs
On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote: > On 24 April 2018 at 20:14, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com> > > wrote: > >> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: > >>> This tries to align with the X.org communities's long-standing > >>> tradition of trying to be an inclusive community and handing out > >>> commit rights fairly freely. > >>> > >>> We also tend to not revoke commit rights for people no longer > >>> regularly active in a given project, as long as they're still part of > >>> the larger community. > >>> > >>> Finally make sure that commit rights, like anything happening on fd.o > >>> infrastructre, is subject to the fd.o's Code of Conduct. > >>> > >>> v2: Point at MAINTAINERS for contact info (Daniel S.) > >>> > >>> v3: > >>> - Make it clear that commit rights are voluntary and that committers > >>> need to acknowledge positively when they're nominated by someone > >>> else (Keith). > >>> - Encourage committers to drop their commit rights when they're no > >>> longer active, and make it clear they'll get readded (Keith). > >>> - Add a line that maintainers and committers should actively nominate > >>> new committers (me). > >>> > >>> v4: Typo (Petri). > >>> > >>> v5: Typo (Sean). > >>> > >>> v6: Wording clarifications and spelling (Jani). > >>> > >>> v7: Require an explicit commitment to the documented merge criteria > >>> and rules, instead of just the implied one through the Code of Conduct > >>> threat (Jani). > >>> > >>> Acked-by: Alex Deucher <alexander.deuc...@amd.com> > >>> Acked-by: Arkadiusz Hiler <arkadiusz.hi...@intel.com> > >>> Acked-by: Daniel Stone <dan...@fooishbar.org> > >>> Acked-by: Eric Anholt <e...@anholt.net> > >>> Acked-by: Gustavo Padovan <gust...@padovan.org> > >>> Acked-by: Petri Latvala <petri.latv...@intel.com> > >>> Cc: Alex Deucher <alexander.deuc...@amd.com> > >>> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> > >>> Cc: Ben Widawsky <b...@bwidawsk.net> > >>> Cc: Daniel Stone <dan...@fooishbar.org> > >>> Cc: Dave Airlie <airl...@gmail.com> > >>> Cc: Eric Anholt <e...@anholt.net> > >>> Cc: Gustavo Padovan <gust...@padovan.org> > >>> Cc: Jani Nikula <jani.nik...@intel.com> > >>> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > >>> Cc: Keith Packard <kei...@keithp.com> > >>> Cc: Kenneth Graunke <kenn...@whitecape.org> > >>> Cc: Kristian H. Kristensen <hoegsb...@google.com> > >>> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> > >>> Cc: Petri Latvala <petri.latv...@intel.com> > >>> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> > >>> Cc: Sean Paul <seanp...@chromium.org> > >>> Reviewed-by: Keith Packard <kei...@keithp.com> > >>> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> > >>> --- > >>> If you wonder about the wide distribution list for an igt patch: I'd > >>> like to start a discussions about x.org community norms around commit > >>> rights at large, at least for all the shared repos. I plan to propose > >>> the same text for drm-misc and libdrm too, and hopefully others like > >>> mesa/xserver/wayland would follow. > >>> > >> I think the idea is pretty good, simply highlighting some bits. > >> > >> What you've outlined in this patch has been in practise for many years: > >> a) undocumented, applicable to most xorg projects [1] > >> b) documented, mesa > > > > Hm, I chatted with a few mesa devs about this, and I wasn't aware > > there's explicit documentation for mesa. Where is it? I'd very much > > want to align as much as we can. > > > See the "Developer git Access" section in [1]. FWIW I prefer the > wording used in this patch and the CoC reference is a big plus. > > HTH > Emil > > [1] https://www.mesa3d.org/repository.html Ah missed this indeed. One thing to note wrt mesa is that this text here relies heavily on _documented_ merge criteria. When I discussed it with mesa we realized that the documented merge criteria do not really match the actual criteria: https://www.mesa3d.org/submittingpatches.html E.g. for many drivers review is mandatory I think, same for core code. And Intel folks require that you go through their CI too. So the bigger part in adopting this for mesa would be in updating the merge criteria doc to reflect reality. Anyway, I'm happy that even the few terse lines match what I'm proposing here (minus lots of details), I think we're good to go. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote: > On 13 April 2018 at 11:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote: >> This tries to align with the X.org communities's long-standing >> tradition of trying to be an inclusive community and handing out >> commit rights fairly freely. >> >> We also tend to not revoke commit rights for people no longer >> regularly active in a given project, as long as they're still part of >> the larger community. >> >> Finally make sure that commit rights, like anything happening on fd.o >> infrastructre, is subject to the fd.o's Code of Conduct. >> >> v2: Point at MAINTAINERS for contact info (Daniel S.) >> >> v3: >> - Make it clear that commit rights are voluntary and that committers >> need to acknowledge positively when they're nominated by someone >> else (Keith). >> - Encourage committers to drop their commit rights when they're no >> longer active, and make it clear they'll get readded (Keith). >> - Add a line that maintainers and committers should actively nominate >> new committers (me). >> >> v4: Typo (Petri). >> >> v5: Typo (Sean). >> >> v6: Wording clarifications and spelling (Jani). >> >> v7: Require an explicit commitment to the documented merge criteria >> and rules, instead of just the implied one through the Code of Conduct >> threat (Jani). >> >> Acked-by: Alex Deucher <alexander.deuc...@amd.com> >> Acked-by: Arkadiusz Hiler <arkadiusz.hi...@intel.com> >> Acked-by: Daniel Stone <dan...@fooishbar.org> >> Acked-by: Eric Anholt <e...@anholt.net> >> Acked-by: Gustavo Padovan <gust...@padovan.org> >> Acked-by: Petri Latvala <petri.latv...@intel.com> >> Cc: Alex Deucher <alexander.deuc...@amd.com> >> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> >> Cc: Ben Widawsky <b...@bwidawsk.net> >> Cc: Daniel Stone <dan...@fooishbar.org> >> Cc: Dave Airlie <airl...@gmail.com> >> Cc: Eric Anholt <e...@anholt.net> >> Cc: Gustavo Padovan <gust...@padovan.org> >> Cc: Jani Nikula <jani.nik...@intel.com> >> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> >> Cc: Keith Packard <kei...@keithp.com> >> Cc: Kenneth Graunke <kenn...@whitecape.org> >> Cc: Kristian H. Kristensen <hoegsb...@google.com> >> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> >> Cc: Petri Latvala <petri.latv...@intel.com> >> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> >> Cc: Sean Paul <seanp...@chromium.org> >> Reviewed-by: Keith Packard <kei...@keithp.com> >> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> >> --- >> If you wonder about the wide distribution list for an igt patch: I'd >> like to start a discussions about x.org community norms around commit >> rights at large, at least for all the shared repos. I plan to propose >> the same text for drm-misc and libdrm too, and hopefully others like >> mesa/xserver/wayland would follow. >> > I think the idea is pretty good, simply highlighting some bits. > > What you've outlined in this patch has been in practise for many years: > a) undocumented, applicable to most xorg projects [1] > b) documented, mesa Hm, I chatted with a few mesa devs about this, and I wasn't aware there's explicit documentation for mesa. Where is it? I'd very much want to align as much as we can. > IMHO having this explicitly documented and others > (wayland/weston/wayland-protocols and xserver repos) following suite > is a big plus. Yeah, that's the idea. Hence plenty of Cc: for this igt patch. -Daniel > > HTH > Emil > > [1] As in all of https://cgit.freedesktop.org/xorg but xserver -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs
This tries to align with the X.org communities's long-standing tradition of trying to be an inclusive community and handing out commit rights fairly freely. We also tend to not revoke commit rights for people no longer regularly active in a given project, as long as they're still part of the larger community. Finally make sure that commit rights, like anything happening on fd.o infrastructre, is subject to the fd.o's Code of Conduct. v2: Point at MAINTAINERS for contact info (Daniel S.) v3: - Make it clear that commit rights are voluntary and that committers need to acknowledge positively when they're nominated by someone else (Keith). - Encourage committers to drop their commit rights when they're no longer active, and make it clear they'll get readded (Keith). - Add a line that maintainers and committers should actively nominate new committers (me). v4: Typo (Petri). v5: Typo (Sean). v6: Wording clarifications and spelling (Jani). v7: Require an explicit commitment to the documented merge criteria and rules, instead of just the implied one through the Code of Conduct threat (Jani). Acked-by: Alex Deucher <alexander.deuc...@amd.com> Acked-by: Arkadiusz Hiler <arkadiusz.hi...@intel.com> Acked-by: Daniel Stone <dan...@fooishbar.org> Acked-by: Eric Anholt <e...@anholt.net> Acked-by: Gustavo Padovan <gust...@padovan.org> Acked-by: Petri Latvala <petri.latv...@intel.com> Cc: Alex Deucher <alexander.deuc...@amd.com> Cc: Arkadiusz Hiler <arkadiusz.hi...@intel.com> Cc: Ben Widawsky <b...@bwidawsk.net> Cc: Daniel Stone <dan...@fooishbar.org> Cc: Dave Airlie <airl...@gmail.com> Cc: Eric Anholt <e...@anholt.net> Cc: Gustavo Padovan <gust...@padovan.org> Cc: Jani Nikula <jani.nik...@intel.com> Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> Cc: Keith Packard <kei...@keithp.com> Cc: Kenneth Graunke <kenn...@whitecape.org> Cc: Kristian H. Kristensen <hoegsb...@google.com> Cc: Maarten Lankhorst <maarten.lankho...@linux.intel.com> Cc: Petri Latvala <petri.latv...@intel.com> Cc: Rodrigo Vivi <rodrigo.v...@intel.com> Cc: Sean Paul <seanp...@chromium.org> Reviewed-by: Keith Packard <kei...@keithp.com> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com> --- If you wonder about the wide distribution list for an igt patch: I'd like to start a discussions about x.org community norms around commit rights at large, at least for all the shared repos. I plan to propose the same text for drm-misc and libdrm too, and hopefully others like mesa/xserver/wayland would follow. fd.o admins also plan to discuss this (and a pile of other topics and hosting and code of conduct) with all projects, ideally this here would end up as the starting point for establishing some community norms. -Daniel --- CONTRIBUTING | 48 1 file changed, 48 insertions(+) diff --git a/CONTRIBUTING b/CONTRIBUTING index 0180641be3aa..8a118134275c 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -51,4 +51,52 @@ A short list of contribution guidelines: - Changes to the testcases are automatically tested. Take the results into account before merging. +Commit rights +- + +Commit rights will be granted to anyone who requests them and fulfills the +below criteria: + +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple + spelling fixes and whitespace adjustment) patches that have been merged + already. + +- Are actively participating on discussions about their work (on the mailing + list or IRC). This should not be interpreted as a requirement to review other + peoples patches but just make sure that patch submission isn't one-way + communication. Cross-review is still highly encouraged. + +- Will be regularly contributing further patches. This includes regular + contributors to other parts of the open source graphics stack who only + do the oddball rare patch within igt itself. + +- Agrees to use their commit rights in accordance with the documented merge + criteria, tools, and processes. + +Apply for an account (and any other account change requests) through + +https://www.freedesktop.org/wiki/AccountRequests/ + +and please ping the maintainers if your request is stuck. + +Committers are encouraged to request their commit rights get removed when they +no longer contribute to the project. Commit rights will be reinstated when they +come back to the project. + +Maintainers and committers should encourage contributors to request commit +rights, especially junior contributors tend to underestimate their skills. + +Code of Conduct +--- + +Please be aware the fd.o Code of Conduct also applies to igt: + +https://www.freedesktop.org/wiki/CodeOfConduct/ + +See the MAINTAINERS file for contact details of the igt maintainers. + +Abuse of commit rights, like engaging in commit fights or willfully pushi
Re: VK_EXT_aquire_xlib_display and kernel security concerns
Just throwing a bit more context into the discussion here. On Mon, Oct 16, 2017 at 11:51 PM, James Jones <jajo...@nvidia.com> wrote: > On 10/16/2017 01:33 PM, Dave Airlie wrote: >> >> On 17 October 2017 at 06:01, James Jones <jajo...@nvidia.com> wrote: >>> >>> On 10/16/2017 12:28 PM, Keith Packard wrote: >>>> >>>> >>>> James Jones <jajo...@nvidia.com> writes: >>>> >>>>> I think at a lower level, we have different views of how >>>>> vkGetPhysicalDeviceDisplayPropertiesKHR/VK_KHR_display works. >>>>> vkGetPhysicalDeviceDisplayPropertiesKHR() is suppose to enumerate all >>>>> the displays on a given device. >>>> >>>> >>>> >>>> In many devices, the display controller and rendering hardware are >>>> separate devices, so it's up to user space to figure out the connection >>>> between them, and user DMAbufs to pass rendered output to the display. >>> >>> >>> >>> Understood. In that case, no displays should be enumerated on the >>> "rendering hardware" device in Vulkan, unless the driver vendor opts for >>> heroics. >>> >>>>> I assumed DRM drivers would try the display-capable node, then fall >>>>> back to a render node if that failed. >>>> >>>> >>>> >>>> No, they cannot as the display node is protected from normal user >>>> access. >>> >>> >>> >>> Right, but normal processes don't need the display node, or aren't >>> supposed >>> to. I assumed apps that need direct-to-display would have elevated >>> permissions on systems configured to require it, or use "acquire" >>> extensions, potentially combined with native secondary auth mechanisms, >>> to >>> get access. This is why it bothers me that "normal user access" doesn't >>> include display enumeration. >> >> >> If they use acquire extensions they get display enumeration, the problem >> is >> display enumeration before the acquire would need special permission >> elevation. >> >>>>> VK_KHR_display, but the core of it is really just a display >>>>> enumeration API. >>>> >>>> >>>> >>>> Right, I think all I really need is to hand the driver a connection to >>>> the X server and it can use that to enumerate the available displays >>>> through the Vulkan API. >> >> >> The thing is if you are running under X I don't think apps should be >> bypassing >> things and going straight to hw enumeration, it makes too many problems >> harder, >> and in systems where all you have are separated display/render devices it >> makes this extension impossible to implement, since as you've said vulkan >> has >> no way to enumerate such things. >>> >>> >>>> >>> >> >>> >>> Given the current definition of a Vulkan-capable device, yes. It's >>> annoying >>> that Vulkan can't yet expose a device that only has displays and the >>> ability >>> to import memory objects and create images from them. >>> >>> I prefer the enumeration ability as a general principle though. Is the >>> discussion with Daniel Vetter captured somewhere so I can read up on the >>> objections? I couldn't find it with a naive Google or DRI devel search. >> >> >> Since we have to actually publish our kernel APIs people find inventive >> ways >> to do things with them that we don't end up breaking later, and having to >> find >> ways to keep their stupid working. You don't have this problem, nobody >> opens >> /dev/nvidia directly from an app and does anything useful, and even if >> they do >> you guys don't care. >> >> Previously for example we opened up DRM_WAIT_VBLANK or forgot to close it, >> this leds to apps directly poking it behind the X server back, trying >> to determine >> timings outside the compositor incorrectly. >> >> So if we expose all the enumeration APIs to "render" only nodes, then we >> will >> get information leaks, like the currently attached framebuffer for >> planes, ways to >> poll state like device connectedness, (we get people trying to bypass dpms >> all >> the time), able to pull the device properties out, it's just a genie >> in a bottle scenario >> once we provide it we can't repeal i
Re: [Mesa-dev] XDC 2017 feedback
On Thu, Sep 28, 2017 at 7:36 AM, Matt Turner <matts...@gmail.com> wrote: > On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark <robdcl...@gmail.com> wrote: >> If you had known of the khr dates, and brought it up in Feb (or really >> somewhat earlier, given that XDC is roughly same time each year +/- >> few weeks), that *might* have been early enough to move things. > > That's unfair. It's part of the X.Org board's responsibilities to plan > conferences and that means being aware of potential conflicts. In > February, six of the eight members of the X.Org board worked for > companies with Khronos access (that's not including Keith who I > suspect has access as well). > > I replied to the 2017-03-02 minutes and noted the conflict, but as you > say that was too late. Unfortunately that was the first time a date > was publicly announced, so I'm not really sure what could have been > done from outside the X.Org board. I don't remember all the details anymore, but we have plumbers right before, and Linaro connect right afterwards, both conferences that also have considerable overlap with XDC (we have a lot more than x86 folks since 2-3 years now). Bunch of people decided not to do XDC this year even, because too much travelling in one row. Plus Google's limit in scheduling a room, plus Khr f2f. We'll try to do better next year, but sometimes perfect scheduling is just not an option. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
XDC 2017 feedback
Hi all, First again big thanks to Stéphane and Jennifer for organizing a great XDC. Like last year we'd like to hear feedback on how this year's XDC went, both the good (and what you'd like to see more of) and the not so good. Talk selection, organization, location, scheduling of talks, anything really. Here's a few things we took into account from Helsinki and tried to apply: - More breaks for more hallway track. - Try to schedule the hot topics on the first day (did we pick the right ones) for better hallway track. - More lightning talk time to give all the late/rejected submissions some place to give a quick showcase. Things that didn't work out perfectly this year and that we'll try to get better at next year: - Lots of people missed the submission deadline and their talks were rejected only because of that. We'll do better PR by sending out a pile of reminders. - Comparitively few people asked for travel assistance. No idea whether this was a year with more budget around, or whether this isn't all that well know and we need to make more PR in maybe the call for papers about it. But that's just the stuff we've gathered already, we'd like to hear more feedback. Just reply to this mail or send a mail to bo...@foundation.x.org if you don't want the entire world to read it. And if you want to send at pseudonymous feedback, drop a pastebin onto the #xf-bod channel on the OFTC irc server. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Mon, Apr 3, 2017 at 8:25 AM, Manasi Navare <manasi.d.nav...@intel.com> wrote: >> So in that case you do need userspace to re-request the same mode at the >> same bpp? > > So yes because when userspace requests the same mode at same bpp, > kernel will still call intel_dp->mod_valid which validates the mode > against 18bpp so if the requested mode can be displayed at the lowest of > 18bpp, then the kernel will try to do the modeset for that mode at lower > bpp. What I am trying to say is irrespective of what bpp userspace requests, > kernel will check if it can display that at the lowest of 18bpp. You're talking about two different bpp here I think. Eric talks about the pixel format of the framebuffer, Manasi here about the bpp we send over the wire. The kernel will auto-dither if the wire bpp is lower than the stuff we scan out. Same with 6bpc panels really. Right now userspace can't request a specific bpp for the sink/pipe, that's fully under the kernel's control. It only gets to set the pixel format of fbs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > On that, I think we could just unconditionally hand leases all encoders. > > Encoders turned out to be a bit an uapi mistake. > > Well, given the complexity of hardware these days, even crtcs would > probably best have been hidden... > > > Neither setcrtc nor atomic use it, the kernel always selects the right > > encoder for you. It's only exposed to give userspace some hints wrt > > routing (and it's pretty bad at describing modern restrictions, which > > often means you get a 1:1 encoder/connector mapping). Unconditionally > > exposing all encoders for all lessees would fix all these troubles. > > Yeah, I can't find encoders passed into any kernel api, other than the > getencoder call. It seems like we can leave them as shared objects not > subject to leasing as they are query-only. I'll go ahead and do > that. The encoder crtc set still needs to be filtered in the query > operation so that the client knows which crtc to use for each output. > > Now as to how we report the kernel objects that have been leased, we > have two options: > > 1) Report them back via the X protocol > > 2) Have the client query the resulting lease for its contents > > I already suggested that the drm query API should be changed to report > both type and id for each leased object, that would make it sufficient > here. Instead of duplicating that over the X protocol, I suggest we just > use the adjusted kernel API. Hm, if you restrict getresources and getplanes, you'll get your leased objects query api. Iirc that part was missing in your kernel patch. And it gives you exaclty what you want: per-type list of object ids. > > > Note that there's also no properties on encoders, those only exist on > > crtc, connector and planes. > > Any thoughts on access control for properties? Right now, the set > property ioctl checks for access to the containing object, but there's > no check when querying properties. This means that you don't need to add > leases on properties. This changes with atomic - without properties you can't change anything using atomic. Otoh maybe we just want to add checks on the containing object for now, some of the finer semantic points like "don't modeset" or "don't steal shared resources at all" can't be expressed (in a generic way at least) by restricting to specific properties anyway. E.g. on many chips changing the fb is only ok if you keep the same stride, pixel format and modifier (~ tiling). -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
e EDID > + packet, stored in big endian order (MSB first). 'code-min' and > + 'code-max' define a closed-interval of Manufacturer product > + codes, which is byte 10 and 11 of the EDID packet, stored in > + little endian order (LSB first). > + > + ❧❧❧ > + > 6. Extension Initialization > > The name of this extension is "RANDR". > @@ -1666,6 +1703,67 @@ dynamic changes in the display environment. > window of the screen. > > ❧❧❧ > + > +7.6. Extension Requests added in version 1.6 of the extension. > + > +┌─── > +RRCreateLease > + window : WINDOW > + crtcs: LISTofCRTC > + outputs: LISTofOUTPUT > + ▶ > + nfd: CARD8 > + lease: FD > +└─── > + Errors: Window, Access, Value, CRTC, Output > + > + Creates a new Lease for the specified crtcs and outputs from > + the screen defined by 'window'. Returns a KMS/DRM file > + descriptor which can control the leased objects directly > + through the kernel. While leased, all resources will appear to > + be 'useless' to clients other than the leasing client as > + follows: > + > + • Crtcs are reported as having no 'possible-outputs' and all > + other values reported as if the crtc were disabled. > + > + • Outputs are reported as having no crtcs they can be > + connected to, no clones they can share a crtc with, will > + report a connection status of Disconnected, and will show > + the current crtc as Disabled. > + > + The lease remains in effect until the file descriptor is > + closed, even if the client holding the lease disconnects from > + the X server. > + > + Returns an Access error if any of the named resources are in > + use or already leased to another client. > + > + Returns a Match error if any of the named resources are in use > + by the X server. > + > +┌─── > +RRCreateOutputGrab > + window : WINDOW > + outputgrab: OUTPUTGRAB > + matches: LISTofEDIDMATCH > +└─── > + Errors: Window, Access, Value, CRTC, Output > + > + Creates an Output Grab with the specified ID on the screen > + associated with 'window'. Any output containing an EDID > + property matching the grab will appear to be disconnected to > + all clients other than the grabbing client. > + > +┌─── > +RRDestroyOutputGrab > + outputgrab: OUTPUTGRAB > +└─── > + Errors: OutputGrab > + > + Destroys the named OUTPUTGRAB. > + > + ❧❧❧ > 8. Extension Events > > Clients MAY select for ConfigureNotify on the root window to be > > > -- > -keith > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > The multi-seat thing sounds like vapourware, I think we should care about > > the vr use-case for now, and only that one. > > Ok, I can live with that, even if I like the idea of a slightly more > general solution. > > > For VR itself I'd go as far as saying that probably our "create lease" > > ioctl should have only the semantics we need to pass one crtc+primary > > plane for pageflipping in a VR compositor, expressed in a flag. > > Yeah, we can't express planes through X anyways. I'll leave the kernel > API with multiple planes as that's actually simpler than having it > validate that only a single plane is in the lease. > > > All the details about additional corner cases are just so unclear to > > me (and there's not even a clear use case that will materialize) that > > I don't think having the uapi is worth it. Too close to the "I'll > > regret this immediately" bucket :-) > > Removing the 'ChangeLease' ioctl eliminates a bunch of complexity in the > code, and means I don't even have to think about sending events. I'll > also go ahead and remove the ability to hide resources from the lessor. > > Thanks, as always, for your thoughtful review. > > ps -- Any thoughts on whether the X request should include the mode to > use? Doing that would let us restrict the lessee from setting modes, > and avoid potential resource issues with the window system. However, it > would also require providing a scanout buffer in the request. Yeah I think that's a pretty neat idea to reduce the lease complexity even more. If the VR compositor is unhappy and wants a different mode, it can simply nuke the lease and as for a new one. Forgot to say that :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Mon, Apr 03, 2017 at 09:41:34AM -0700, Keith Packard wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > Hm, if you restrict getresources and getplanes, you'll get your leased > > objects query api. Iirc that part was missing in your kernel patch. And it > > gives you exaclty what you want: per-type list of object ids. > > Hrm. I think that's one Dave didn't want to restrict so that > applications don't see resources disappear and get confused. But, > perhaps a simple variant of those instead of a completely different API. On the X side we don't want to restrict. But the VR client better be able to deal with not seeing or being able to use everything. Also if this confuses VR, then another reason why we want to make leases invariant and only allow pure revoke, not changing the list. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > Also if this confuses VR, then another reason why we want to make leases > > invariant and only allow pure revoke, not changing the list. > > I'm not sure why you want this to be asymmetrical, nor why you would > expect lessees to be any more competent at dealing with hotplug than the > lessor. > > One use case already proposed for this API was to allow for multi-seat, > where the lessee would be an existing window system, which we already > accept as being incompetent at dealing with resource hotplug. I imagine > that in this case, a newly plugged monitor would be detected by the > multi-seat manager (logind?) and added to one of the existing leases, > along with a suitable CRTC resource. For this to work, the lessee will > need to already know about those resources and only have their > connectivity status hidden. The multi-seat thing sounds like vapourware, I think we should care about the vr use-case for now, and only that one. And for that restricting stuff is perfectly fine. Of course we can design the entire thing in a way that doesn't draw us into a corner in the future right away, but that's mostly on the implementation side. For VR itself I'd go as far as saying that probably our "create lease" ioctl should have only the semantics we need to pass one crtc+primary plane for pageflipping in a VR compositor, expressed in a flag. All the details about additional corner cases are just so unclear to me (and there's not even a clear use case that will materialize) that I don't think having the uapi is worth it. Too close to the "I'll regret this immediately" bucket :-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote: > Manasi Navare <manasi.d.nav...@intel.com> writes: > > > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote: > >> Manasi Navare <manasi.d.nav...@intel.com> writes: > >> > >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote: > >> >> Martin Peres <martin.pe...@linux.intel.com> writes: > >> >> > >> >> > On 26/01/17 14:37, Martin Peres wrote: > >> >> >> Despite all the careful planing of the kernel, a link may become > >> >> >> insufficient to handle the currently-set mode. At this point, the > >> >> >> kernel should mark this particular configuration as being broken > >> >> >> and potentially prune the mode before setting the offending > >> >> >> connector's > >> >> >> link-status to BAD and send the userspace a hotplug event. This may > >> >> >> happen right after a modeset or later on. > >> >> >> > >> >> >> When available, we should use the link-status information to reset > >> >> >> the wanted mode. > >> >> >> > >> >> >> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > >> >> > > >> >> > The relevant kernel patches have landed in drm-tip about a month ago. > >> >> > > >> >> > Eric, would you mind providing feedback on or merging this patch? > >> >> > >> >> The later discussion has sounded like the kernel will (always) prune the > >> >> mode when we re-query, meaning that it doesn't make any sense to try to > >> >> re-set to the old mode. Is this not the case? > >> > > >> > > >> > No the kernel will simply send a hotplug with link status as bad > >> > and then after that point its userspace driver's responsibility > >> > to check if link status is BAD, retry the same mode and if it fails > >> > then re probe. > >> > >> So the kernel will sometimes allow the same mode to be re-set with the > >> same bpp? > > > > So when userspace driver re-sets the same mode, the kernel will call the > > mode valid function where it will see it can allow the sam mode perhaps > > at a lower bpp now since the link parameters are lowered. > > So the mode which failed at 30 bpp, might still work at 18bpp and is > > better going to a lower resolution. > > The question was whether the kernel will ever allow the same mode at the > same bpp, since that's what this patch tries to do. Yes, this can happen. Doing a full modeset with recomputing clocks and everything behind userspace's back might not be something the kernel driver can pull of with a reasonable amount of effort, hence why we punt to userspace. The interface spec makes this a CAN, not WILL, to allow less unreasonable hw to handle these cases directly in the kernel driver. E.g. plain link-retraining is handled in i915.ko still. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Thu, Feb 02, 2017 at 09:57:20AM -0800, Eric Anholt wrote: > Daniel Vetter <dan...@ffwll.ch> writes: > > > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > >> Jani Nikula <jani.nik...@linux.intel.com> writes: > >> > >> > On Tue, 31 Jan 2017, Eric Anholt <e...@anholt.net> wrote: > >> >> Martin Peres <martin.pe...@linux.intel.com> writes: > >> >> > >> >>> Despite all the careful planing of the kernel, a link may become > >> >>> insufficient to handle the currently-set mode. At this point, the > >> >>> kernel should mark this particular configuration as being broken > >> >>> and potentially prune the mode before setting the offending connector's > >> >>> link-status to BAD and send the userspace a hotplug event. This may > >> >>> happen right after a modeset or later on. > >> >>> > >> >>> When available, we should use the link-status information to reset > >> >>> the wanted mode. > >> >>> > >> >>> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > >> >> > >> >> If I understand this right, there are two failure modes being handled: > >> >> > >> >> 1) A mode that won't actually work because the link isn't good enough. > >> >> > >> >> 2) A mode that should work, but link parameters were too optimistic and > >> >> if we just ask the kernel to set the mode again it'll use more > >> >> conservative parameters that work. > >> >> > >> >> This patch seems good for 2). For 1), the drmmode_set_mode_major is > >> >> going to set our old mode back. Won't the modeset then fail to link > >> >> train again, and bring us back into this loop? The only escape that I > >> >> see would be some other userspace responding to the advertised mode list > >> >> changing, and then asking X to modeset to something new. > >> >> > >> >> To avoid that failure busy loop, should we re-fetching modes at this > >> >> point, and only re-setting if our mode still exists? > >> > > >> > Disclaimer: I don't know anything about the internals of the modesetting > >> > driver. > >> > > >> > Perhaps we can identify the two cases now, but I'd put this more > >> > generally: if the link status has gone bad, it's an indicator to > >> > userspace that the circumstances may have changed, and userspace should > >> > query the kernel for the list of available modes again. It should no > >> > longer trust information obtained prior to getting the bad link status, > >> > including the current mode. > >> > > >> > But specifically, I think you're right, and AFAICT asking for the list > >> > of modes again is the only way for the userspace to distinguish between > >> > the two cases. I don't think there's a shortcut for deciding the current > >> > mode is still valid. > >> > >> To avoid the busy-loop problem, I think I'd like this patch to re-query > >> the kernel to ask about the current mode list, and only try to re-set > >> the mode if our mode is still there. > > > > Yeah, I guess that sounds like a reasonable heuristics. More integrated > > compositors (aka the wayland ones) might be able to make more useful > > decisions, but for -modesetting that's probably the best we can do. > > > >> If the mode isn't there, then it's up to the DE to take action in > >> response to the notification of new modes. If you don't have a DE to > >> take appropriate action, you're kind of out of luck. > >> > >> As far as the ABI goes, this seems fine to me. The only concern I had > >> about ABI was having to walk all the connectors on every uevent to see > >> if any had gone bad -- couldn't we have a flag of some sort about what > >> the uevent indicates? But uevents should be super rare, so I'd say the > >> kernel could go ahead with the current plan. > > > > We've discussed finer-grained uevent singalling a few times, and I'd like > > that to be an orthogonal abi extension. Right now we just don't have the > > required tracking even within the kernel to know which connector changed > > (and the tracking we do have missed a few things, too). My idea is to push > > the tracking into the leaves of the callchains with a function tha
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Tue, Feb 28, 2017 at 04:07:02AM +, Navare, Manasi D wrote: > > On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote: > > Hi Daniel, > > > > We have ACKs on the userspace design from both Adams and Eric. > > Is this enough to merge the kernel patches? > > > > I spoke to Eric briefly about this and he gave me a verbal r-b as well. > > He said the userspace patches cant get merged unless DRM patches are merged. > > > > So what should be some of our next steps here? > > Still needs review on the kernel patches themselves, iirc Jani still had some > opens on that. But I was out of the loop for 2 weeks :-) -Daniel > > Thanks for merging the 1st patch in the kernel series. Are there any opens on > the 2nd patch (the i915 patch)? > I wanted to actually respin the 2nd patch to add reset for > intel_dp->lane_count on the link training failure so that it doesn't > accidently retrain the link with the stale/failed values. Didn't look like that, and we can do this as a follow-up. I only asked where we should merge it for best results. Let's continue that discussion in the other thread. -Daniel > > Regards > Manasi > > > > > Regards > > Manasi > > > > > > On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote: > > > Martin Peres <martin.pe...@linux.intel.com> writes: > > > > > > > On 06/02/17 17:50, Martin Peres wrote: > > > >> On 03/02/17 10:04, Daniel Vetter wrote: > > > >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote: > > > >>>> On 01/02/17 22:05, Manasi Navare wrote: > > > >>>>> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > > > >>>>>> Jani Nikula <jani.nik...@linux.intel.com> writes: > > > >>>>>> > > > >>>>>>> On Tue, 31 Jan 2017, Eric Anholt <e...@anholt.net> wrote: > > > >>>>>>>> Martin Peres <martin.pe...@linux.intel.com> writes: > > > >>>>>>>> > > > >>>>>>>>> Despite all the careful planing of the kernel, a link may > > > >>>>>>>>> become insufficient to handle the currently-set mode. At > > > >>>>>>>>> this point, the kernel should mark this particular > > > >>>>>>>>> configuration as being broken and potentially prune the > > > >>>>>>>>> mode before setting the offending connector's link-status > > > >>>>>>>>> to BAD and send the userspace a hotplug event. This may > > > >>>>>>>>> happen right after a modeset or later on. > > > >>>>>>>>> > > > >>>>>>>>> When available, we should use the link-status information > > > >>>>>>>>> to reset the wanted mode. > > > >>>>>>>>> > > > >>>>>>>>> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > > > >>>>>>>> If I understand this right, there are two failure modes > > > >>>>>>>> being > > > >>>>>>>> handled: > > > >>>>>>>> > > > >>>>>>>> 1) A mode that won't actually work because the link isn't > > > >>>>>>>> good enough. > > > >>>>>>>> > > > >>>>>>>> 2) A mode that should work, but link parameters were too > > > >>>>>>>> optimistic and if we just ask the kernel to set the mode > > > >>>>>>>> again it'll use more conservative parameters that work. > > > >>>>>>>> > > > >>>>>>>> This patch seems good for 2). For 1), the > > > >>>>>>>> drmmode_set_mode_major is going to set our old mode back. > > > >>>>>>>> Won't the modeset then fail to link train again, and bring > > > >>>>>>>> us back into this loop? The only escape that I see would > > > >>>>>>>> be some other userspace responding to the advertised mode > > > >>>>>>>> list changing, and then asking X to modeset to something > > > >>>>>>>> new. > > > >>>>>>>
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Fri, Feb 24, 2017 at 12:09:51PM -0800, Manasi Navare wrote: > Hi Daniel, > > We have ACKs on the userspace design from both Adams and Eric. > Is this enough to merge the kernel patches? > > I spoke to Eric briefly about this and he gave me a verbal r-b as well. > He said the userspace patches cant get merged unless DRM patches are merged. > > So what should be some of our next steps here? Still needs review on the kernel patches themselves, iirc Jani still had some opens on that. But I was out of the loop for 2 weeks :-) -Daniel > > Regards > Manasi > > > On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote: > > Martin Peres <martin.pe...@linux.intel.com> writes: > > > > > On 06/02/17 17:50, Martin Peres wrote: > > >> On 03/02/17 10:04, Daniel Vetter wrote: > > >>> On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote: > > >>>> On 01/02/17 22:05, Manasi Navare wrote: > > >>>>> On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > > >>>>>> Jani Nikula <jani.nik...@linux.intel.com> writes: > > >>>>>> > > >>>>>>> On Tue, 31 Jan 2017, Eric Anholt <e...@anholt.net> wrote: > > >>>>>>>> Martin Peres <martin.pe...@linux.intel.com> writes: > > >>>>>>>> > > >>>>>>>>> Despite all the careful planing of the kernel, a link may become > > >>>>>>>>> insufficient to handle the currently-set mode. At this point, the > > >>>>>>>>> kernel should mark this particular configuration as being broken > > >>>>>>>>> and potentially prune the mode before setting the offending > > >>>>>>>>> connector's > > >>>>>>>>> link-status to BAD and send the userspace a hotplug event. This > > >>>>>>>>> may > > >>>>>>>>> happen right after a modeset or later on. > > >>>>>>>>> > > >>>>>>>>> When available, we should use the link-status information to reset > > >>>>>>>>> the wanted mode. > > >>>>>>>>> > > >>>>>>>>> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > > >>>>>>>> If I understand this right, there are two failure modes being > > >>>>>>>> handled: > > >>>>>>>> > > >>>>>>>> 1) A mode that won't actually work because the link isn't good > > >>>>>>>> enough. > > >>>>>>>> > > >>>>>>>> 2) A mode that should work, but link parameters were too > > >>>>>>>> optimistic and > > >>>>>>>> if we just ask the kernel to set the mode again it'll use more > > >>>>>>>> conservative parameters that work. > > >>>>>>>> > > >>>>>>>> This patch seems good for 2). For 1), the drmmode_set_mode_major > > >>>>>>>> is > > >>>>>>>> going to set our old mode back. Won't the modeset then fail to > > >>>>>>>> link > > >>>>>>>> train again, and bring us back into this loop? The only escape > > >>>>>>>> that I > > >>>>>>>> see would be some other userspace responding to the advertised > > >>>>>>>> mode list > > >>>>>>>> changing, and then asking X to modeset to something new. > > >>>>>>>> > > >>>>>>>> To avoid that failure busy loop, should we re-fetching modes at > > >>>>>>>> this > > >>>>>>>> point, and only re-setting if our mode still exists? > > >>>>>>> Disclaimer: I don't know anything about the internals of the > > >>>>>>> modesetting > > >>>>>>> driver. > > >>>>>>> > > >>>>>>> Perhaps we can identify the two cases now, but I'd put this more > > >>>>>>> generally: if the link status has gone bad, it's an indicator to > > >>>>>>> userspace that the circumstances may have changed, and userspace >
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Fri, Feb 03, 2017 at 01:30:14AM +0200, Martin Peres wrote: > On 01/02/17 22:05, Manasi Navare wrote: > > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > > > Jani Nikula <jani.nik...@linux.intel.com> writes: > > > > > > > On Tue, 31 Jan 2017, Eric Anholt <e...@anholt.net> wrote: > > > > > Martin Peres <martin.pe...@linux.intel.com> writes: > > > > > > > > > > > Despite all the careful planing of the kernel, a link may become > > > > > > insufficient to handle the currently-set mode. At this point, the > > > > > > kernel should mark this particular configuration as being broken > > > > > > and potentially prune the mode before setting the offending > > > > > > connector's > > > > > > link-status to BAD and send the userspace a hotplug event. This may > > > > > > happen right after a modeset or later on. > > > > > > > > > > > > When available, we should use the link-status information to reset > > > > > > the wanted mode. > > > > > > > > > > > > Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > > > > > If I understand this right, there are two failure modes being handled: > > > > > > > > > > 1) A mode that won't actually work because the link isn't good enough. > > > > > > > > > > 2) A mode that should work, but link parameters were too optimistic > > > > > and > > > > > if we just ask the kernel to set the mode again it'll use more > > > > > conservative parameters that work. > > > > > > > > > > This patch seems good for 2). For 1), the drmmode_set_mode_major is > > > > > going to set our old mode back. Won't the modeset then fail to link > > > > > train again, and bring us back into this loop? The only escape that I > > > > > see would be some other userspace responding to the advertised mode > > > > > list > > > > > changing, and then asking X to modeset to something new. > > > > > > > > > > To avoid that failure busy loop, should we re-fetching modes at this > > > > > point, and only re-setting if our mode still exists? > > > > Disclaimer: I don't know anything about the internals of the modesetting > > > > driver. > > > > > > > > Perhaps we can identify the two cases now, but I'd put this more > > > > generally: if the link status has gone bad, it's an indicator to > > > > userspace that the circumstances may have changed, and userspace should > > > > query the kernel for the list of available modes again. It should no > > > > longer trust information obtained prior to getting the bad link status, > > > > including the current mode. > > > > > > > > But specifically, I think you're right, and AFAICT asking for the list > > > > of modes again is the only way for the userspace to distinguish between > > > > the two cases. I don't think there's a shortcut for deciding the current > > > > mode is still valid. > > > To avoid the busy-loop problem, I think I'd like this patch to re-query > > > the kernel to ask about the current mode list, and only try to re-set > > > the mode if our mode is still there. > > > > > > If the mode isn't there, then it's up to the DE to take action in > > > response to the notification of new modes. If you don't have a DE to > > > take appropriate action, you're kind of out of luck. > > > > > > As far as the ABI goes, this seems fine to me. The only concern I had > > > about ABI was having to walk all the connectors on every uevent to see > > > if any had gone bad -- couldn't we have a flag of some sort about what > > > the uevent indicates? But uevents should be super rare, so I'd say the > > > kernel could go ahead with the current plan. > > Yes I agree. The kernel sets the link status BAD as soona s link training > > fails > > but does not prune the modes until a new modelist is requested by the > > userspace. > > So this patch should re query the mode list as soon as it sees the link > > status > > BAD in order for the kernel to validate the modes again based on new link > > paarmeters and send a new mode list back. > > Seems like a bad behaviour from the kernel, isn't it? It should return > immediatly > if the mode
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > Jani Nikula <jani.nik...@linux.intel.com> writes: > > > On Tue, 31 Jan 2017, Eric Anholt <e...@anholt.net> wrote: > >> Martin Peres <martin.pe...@linux.intel.com> writes: > >> > >>> Despite all the careful planing of the kernel, a link may become > >>> insufficient to handle the currently-set mode. At this point, the > >>> kernel should mark this particular configuration as being broken > >>> and potentially prune the mode before setting the offending connector's > >>> link-status to BAD and send the userspace a hotplug event. This may > >>> happen right after a modeset or later on. > >>> > >>> When available, we should use the link-status information to reset > >>> the wanted mode. > >>> > >>> Signed-off-by: Martin Peres <martin.pe...@linux.intel.com> > >> > >> If I understand this right, there are two failure modes being handled: > >> > >> 1) A mode that won't actually work because the link isn't good enough. > >> > >> 2) A mode that should work, but link parameters were too optimistic and > >> if we just ask the kernel to set the mode again it'll use more > >> conservative parameters that work. > >> > >> This patch seems good for 2). For 1), the drmmode_set_mode_major is > >> going to set our old mode back. Won't the modeset then fail to link > >> train again, and bring us back into this loop? The only escape that I > >> see would be some other userspace responding to the advertised mode list > >> changing, and then asking X to modeset to something new. > >> > >> To avoid that failure busy loop, should we re-fetching modes at this > >> point, and only re-setting if our mode still exists? > > > > Disclaimer: I don't know anything about the internals of the modesetting > > driver. > > > > Perhaps we can identify the two cases now, but I'd put this more > > generally: if the link status has gone bad, it's an indicator to > > userspace that the circumstances may have changed, and userspace should > > query the kernel for the list of available modes again. It should no > > longer trust information obtained prior to getting the bad link status, > > including the current mode. > > > > But specifically, I think you're right, and AFAICT asking for the list > > of modes again is the only way for the userspace to distinguish between > > the two cases. I don't think there's a shortcut for deciding the current > > mode is still valid. > > To avoid the busy-loop problem, I think I'd like this patch to re-query > the kernel to ask about the current mode list, and only try to re-set > the mode if our mode is still there. Yeah, I guess that sounds like a reasonable heuristics. More integrated compositors (aka the wayland ones) might be able to make more useful decisions, but for -modesetting that's probably the best we can do. > If the mode isn't there, then it's up to the DE to take action in > response to the notification of new modes. If you don't have a DE to > take appropriate action, you're kind of out of luck. > > As far as the ABI goes, this seems fine to me. The only concern I had > about ABI was having to walk all the connectors on every uevent to see > if any had gone bad -- couldn't we have a flag of some sort about what > the uevent indicates? But uevents should be super rare, so I'd say the > kernel could go ahead with the current plan. We've discussed finer-grained uevent singalling a few times, and I'd like that to be an orthogonal abi extension. Right now we just don't have the required tracking even within the kernel to know which connector changed (and the tracking we do have missed a few things, too). My idea is to push the tracking into the leaves of the callchains with a function that increases some per-connector epoch counter. Then we'd just have to expose that somehow cheaply to userspace (could probably just send it along in the uevent). Plus expose it as a read-only property so that userspace can re-synchronize. But again, that should be an orthogonal thing imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
rent mode. You may be > left" > + "with a black screen if this fails...\n", con_id); > +} > +drmModeFreeProperty(props); > +} > +drmModeFreeConnector(koutput); > +} > + > mode_res = drmModeGetResources(drmmode->fd); > if (!mode_res) > goto out; > @@ -2345,6 +2392,10 @@ out_free_res: > out: > RRGetInfo(xf86ScrnToScreen(scrn), TRUE); > } > + > +#undef DRM_MODE_LINK_STATUS_BAD > +#undef DRM_MODE_LINK_STATUS_GOOD > + > #endif > > void > -- > 2.11.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] Time to update GSoC/EVoC ideas page
On Fri, Jan 20, 2017 at 08:44:19AM -0800, Jason Ekstrand wrote: > On Fri, Jan 20, 2017 at 2:15 AM, Nicolai Hähnle <nhaeh...@gmail.com> wrote: > > > Hi Rob, > > > > On 19.01.2017 23:32, Rob Clark wrote: > > > >> Just a friendly reminder that now would be a good time to update the > >> wiki page for GSoC/EVoC ideas: > >> > >> https://www.x.org/wiki/SummerOfCodeIdeas/ > >> > >> There are currently still some stale ideas there (and probably plenty > >> of missing good ideas). > >> > >> Also, I've added a "Potential Mentors" section. Please add yourself > >> if you are willing to be a mentor (and what sorts of projects you > >> would be willing to mentor) > >> > > > > I'd be happy to be listed as a possible mentor on the DriConf replacement > > project (nha on IRC/freenode), but I either don't have a Wiki account or > > forgot it a long time ago. Could you put my name down on the page? > > > > Pro tip: You can just git clone the wiki, change a markdown file, and git > push it back up. That's the way I always make edits. Way nicer than a web > GUI. :-) And if you have a shell account, it's easy to resurrect your web wiki account: https://wiki.freedesktop.org/sitewranglers/wiki/401/ Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Request for Proposal for XDC 2017
Hi all, The X.org board is soliciting proposals to host XDC in 2017. By the usual rotation a location in north america is preferred, but the board will also consider other locations, especially if there's an interesting co-location with another conference. If you consider hosting XDC, we have assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ If possible the board would like to decide on the next location at XDC 2016 in Helsinki, please submit your proposal with at least the key information about location, possible dates and estimated costs to bo...@foundation.x.org latest by 31th August. An early quick heads-up to the board if you consider hosting would also be good, in case we need to adjust the schedule a bit. Also earlier is better since in generally there will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with a previous organizers, or with someone from the board. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Request for Proposal for XDC 2016
Hi all, The X.Org board is solicting further proposals to organize XDC somewhere in Europe. The board has already received a proposal for Helsinki and plans to vote on that in the next meeting on the 29th Oct, but if there is anyone else interested in hosting XDC we'd very much like to hear about that. Please send in your proposal to bo...@foundation.x.org latest by 28th Oct to make sure the baord can consider it. Thanks, Daniel, secretary of the board -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools 1/7] Fix #ifdef check for _SC_AVPHYS_PAGES in intel_get_avail_ram_mb()
On Tue, Dec 23, 2014 at 07:07:08PM -0800, Alan Coopersmith wrote: Check for the sysconf value used here, not the one used in the previous function. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Thanks for the patches, all merged. Aside: Do you really run all the testcases on solaris or wouldn't it be better to just disable them? And please cc intel-gfx for igt patches and Thomas Wood (who's doing maintainer duties for it now) in the future. Thanks, Daniel --- lib/intel_os.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/intel_os.c b/lib/intel_os.c index db7889b..1badd3e 100644 --- a/lib/intel_os.c +++ b/lib/intel_os.c @@ -112,7 +112,7 @@ intel_get_avail_ram_mb(void) retval = sysinf.freeram; retval *= sysinf.mem_unit; -#elif defined(_SC_PAGESIZE) defined(_SC_PHYS_PAGES) /* Solaris */ +#elif defined(_SC_PAGESIZE) defined(_SC_AVPHYS_PAGES) /* Solaris */ long pagesize, npages; pagesize = sysconf(_SC_PAGESIZE); -- 1.7.9.2 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: tile property contents
On Fri, Oct 24, 2014 at 05:25:58PM +1000, Dave Airlie wrote: There are also configurations where users configure multiple heads to drive power walls that they want to be treated as one logical monitor, similar to the DP MST tiled display case. Normally, those powerwall configurations don't have any layout information from the monitors themselves, and the layout is configured by the user. Would it be appropriate for users to be able to set the TILE property in that sort of scenario? For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc should be expressed in pixels rather than tiles? Sometimes, the tiles in those powerwalls may not all have the same resolution, or may be configured with overlap. I suppose that would make the TILE configuration specific to the current modetimings on each tile... Why can't users just set that mode? Sure, users can set the mode, but: * Part of what the TILE property conveys is how monitors should be grouped for purposes of window maximization. Users don't have a great way to express that today, that I'm aware of. My understanding for why we want the TILE property is to avoid to duplicate displayId parsing over every bit of userspace (and the fbcon stuff in the kernel) interested in it. Imo the proper way for userspace is to always just inherit whatever modeset config is already there. Andy's idea is good, I'd considered it before, the problem being how to expose it nicely, not sure if you'd want persistent via /sys or dynamic setting of the property by user for that session, so we could do it like xrandr modes. Daniel you are missing the nice case of using TILE for non-displayid monitors once the infrastructure is in place. Having it so you can create user defined tile groups to allow users to configure arbitrary walls is a useful thing, that you can't do any other way. * Users might configure the mode they want, but then gnome-settings-daemon may come along later and decide it knows better than the user how things should be configured. One scenario where this comes up is: (a) user meticulously configures his power wall (b) user hotplugs another monitor I've definitely seen cases where window managers will try to be clever in response to a hotplug, and clobber the user's current configuration. If the TILE property conveyed how some set of monitors was supposed to be grouped, that would hopefully give window managers additional information, such that they would know to keep that group intact. Well, imnsho gnome display control center is a bit too opiniated about automatic modeset changes. If their assumption is that they always know perfectly what the user wants upon hotplug I really don't want to work around this in the kernel. Since for everything else than a laptop + beamer gnome panel always pisses me off ;-) I think gnome should just ask the user what it wants if there's more than 2 physical displays (treating a tiled 4k screen as one ofc), since there's really no way at all to tell. Well its not just a GNOME problem either, once things like SDL respect tIle properrty, we can create arbitary tile walls that the whole stack will respect, instead of hacks like fake xinerama. Hm yeah if we want tile walls als logical displays for full-screening and all that then this makes indeed sense. I didn't really consider that part, was probably thrown off by Andy's comments that some tile walls aren't pixel aligned which would look funky for full-screen apps I guess. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: tile property contents
On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote: On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote: On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@nvidia.com wrote: I assume the TILE property described below would be per-connector? It looks like this would handle the DP MST tiled display case. At the risk of trying to solve too much at once: There are also configurations where users configure multiple heads to drive power walls that they want to be treated as one logical monitor, similar to the DP MST tiled display case. Normally, those powerwall configurations don't have any layout information from the monitors themselves, and the layout is configured by the user. Would it be appropriate for users to be able to set the TILE property in that sort of scenario? For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc should be expressed in pixels rather than tiles? Sometimes, the tiles in those powerwalls may not all have the same resolution, or may be configured with overlap. I suppose that would make the TILE configuration specific to the current modetimings on each tile... Why can't users just set that mode? Sure, users can set the mode, but: * Part of what the TILE property conveys is how monitors should be grouped for purposes of window maximization. Users don't have a great way to express that today, that I'm aware of. My understanding for why we want the TILE property is to avoid to duplicate displayId parsing over every bit of userspace (and the fbcon stuff in the kernel) interested in it. Imo the proper way for userspace is to always just inherit whatever modeset config is already there. * Users might configure the mode they want, but then gnome-settings-daemon may come along later and decide it knows better than the user how things should be configured. One scenario where this comes up is: (a) user meticulously configures his power wall (b) user hotplugs another monitor I've definitely seen cases where window managers will try to be clever in response to a hotplug, and clobber the user's current configuration. If the TILE property conveyed how some set of monitors was supposed to be grouped, that would hopefully give window managers additional information, such that they would know to keep that group intact. Well, imnsho gnome display control center is a bit too opiniated about automatic modeset changes. If their assumption is that they always know perfectly what the user wants upon hotplug I really don't want to work around this in the kernel. Since for everything else than a laptop + beamer gnome panel always pisses me off ;-) I think gnome should just ask the user what it wants if there's more than 2 physical displays (treating a tiled 4k screen as one ofc), since there's really no way at all to tell. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: tile property contents
On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@nvidia.com wrote: I assume the TILE property described below would be per-connector? It looks like this would handle the DP MST tiled display case. At the risk of trying to solve too much at once: There are also configurations where users configure multiple heads to drive power walls that they want to be treated as one logical monitor, similar to the DP MST tiled display case. Normally, those powerwall configurations don't have any layout information from the monitors themselves, and the layout is configured by the user. Would it be appropriate for users to be able to set the TILE property in that sort of scenario? For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc should be expressed in pixels rather than tiles? Sometimes, the tiles in those powerwalls may not all have the same resolution, or may be configured with overlap. I suppose that would make the TILE configuration specific to the current modetimings on each tile... Why can't users just set that mode? And if this is about the initial configuration problem then we (at intel) are working on some way to load a dt blob as a firmware image which would contain the entire kms state, and which we'd apply in an atomic modeset at driver load. Everyone else (boot splash, X, ...) will then just inherit that config. That should give you even flicker-free screen walls if you want to ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] linux: Automatically ShareVTs if the VT are already in graphics mode
On Thu, Aug 14, 2014 at 11:36:11AM +0100, Chris Wilson wrote: On Wed, Aug 13, 2014 at 10:58:54AM +0100, Chris Wilson wrote: If the VT we are using is already in KD_GRAPHICS mode, calling SETACTIVE will silently fail. This leads to an indefinite hang as WAITACTIVE never returns causing lockups on boot. This issue becomes apparent when the kernel driver does not install a fbdev for kernel to use for consoles and plymouth leaves the VT in graphics mode. It stops the hang on boot, but it also leaves process control on the defunct VT (i.e. ^C kills Xorg). Can we do the console switch without WAITACTIVE? Also doesn't explain why it works the second time. So this is the comment from the clueless guy who created this mess, but I've thought the entire point of the dummy console (which should still be there) is that all the VT switching still works as if there's a real console. At least my minimal testing with a few X servers seemed to indicate that that still worked ... Or did you manage to get rid of the dummy console, too? That would be a bug in the Kconfig logic we currently have. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] gpu outputs slave and cache flushing
On Tue, Jul 30, 2013 at 09:13:48AM +0100, Chris Wilson wrote: On Tue, Jul 30, 2013 at 03:04:22PM +1000, Dave Airlie wrote: Hey, so I put a patch into intel driver a while ago to avoid doing a bo flush using map/unmap for output slave device if the kernel has vmap flushing However on reflection I realised this only works for CPU accessing devices like UDL but doesn't work for GPU accessing devices like nouveau/radeon, Going forward I'm sure we'll eventually get GPU sync via Maarten's patches but I'm thinking I should revert this change in the intel driver for now, so reverse optimus can work properly Anyone got any ideas for a better plan going forward, maybe a stop gap before Maartens patches. I don't think it is possible to w/a this in userspace, so let's blame Daniel^WBen for this mess and cheer on our knight in shining armour. Go Maarten! But we need to be sure there is a similar synchronisation point for CPU access to a foriegn dma-buf. Yeah, as long as we haven't thought all prime drivers and dma_buf how to sync access (and flush caches if required) userspace needs to manually flush stuff. I don't see a way around this :( On the plus side our QA has started another try at running with nouveau (last time around was just too much fallout from nouveau) to run our neat seat of prime tests. So investing into a few good tests there should pay of nicely. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergström tbergst...@nvidia.com wrote: On 11.06.2013 15:09, Daniel Vetter wrote: Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN is used to restart the ioctl if we had to kick a thread (to make sure it doesn't hold any locks), e.g. for a blocking wait on oustanding rendering. The codepaths taken work exactly as if the thread is interrupt with a signal. You did make it clear that there's no resubmission, but other parts confused me. So this is used so that a legacy driver which does not do fine-grained locking can interrupt all waits for completion for a wedged submit. This way a driver-wide lock get unlocked, cleanup code acquires locks, does the magic to unwedge GPU, and unlocks. Then user space can re-submit the waits as it got -EAGAIN. I think this is not just for drivers without fine-grained locking, at least I expect that we'll keep the same mechanism when switching over to per-object locking - we simply have too many places where a thread could arbitrarily block while holding locks that the gpu reset handler also needs to grab. You could of course restructure the code massively and drop all locks while waiting, but that means adding tons of special-purpose code which is only really exercises when a gpu hang occurs. Our approach with the ioctl restart otoh reuses codepaths which are all heavily used by X (due to X constantly getting interrupt by timers and input events). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value
On Tue, Jun 11, 2013 at 12:48 PM, Thierry Reding thierry.red...@gmail.com wrote: On Tue, May 28, 2013 at 01:12:12PM -0600, Keith Packard wrote: Thierry Reding thierry.red...@gmail.com writes: That doesn't sound right. Maybe drmIoctl() needs fixing instead. Looking at the history, drmIoctl() was introduced to automatically loop if a signal was received (commit 8b9ab108ec1f2ba2b503f713769c4946849b3cb2). However the ioctl(3p) manpage doesn't mention that ioctl() returns EAGAIN in case it is interrupted by a signal. EAGAIN is being returned when the GPU is wedged to ask the application to re-submit the request, which will presumably be held until the GPU is un-wedged. Isn't that a bit risky? What if something special needs to be done to unwedge the GPU other than re-submit the request, or if it just can't be reasonably unwedged. In that case drmIoctl() will keep looping indefinitely. If the above is indeed the expected behaviour for drivers, then we need a different error code for the SYNCPT_WAIT ioctl. EAGAIN is the best fit and anything else doesn't quite match the use-case. A different option might be not to use drmIoctl() on Tegra. We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer which blew up the gpu (that one has been submitted already in a different ioctl call), but to be able to restart the ioctl after the reset has completed: We need to kick every thread which is potentially holding GEM locks and make sure that we block them (at a point where they don't hold any locks) until the reset handler completed. To avoid a validation nightmare we use the same codepaths as we use for signal interrupts, so ioctl restarting is a very natural fit for this. Resubmitting victim workloads when a gpu crash happened is something the reset handler would do (kernel work item currently), not any userspace process doing an ioctl. But atm we don't resubmit victimized workloads. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/6] gpu: host1x: Fix syncpoint wait return value
On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström tbergst...@nvidia.com wrote: On 11.06.2013 14:00, Daniel Vetter wrote: We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer which blew up the gpu (that one has been submitted already in a different ioctl call), but to be able to restart the ioctl after the reset has completed: We need to kick every thread which is potentially holding GEM locks and make sure that we block them (at a point where they don't hold any locks) until the reset handler completed. To avoid a validation nightmare we use the same codepaths as we use for signal interrupts, so ioctl restarting is a very natural fit for this. Resubmitting victim workloads when a gpu crash happened is something the reset handler would do (kernel work item currently), not any userspace process doing an ioctl. But atm we don't resubmit victimized workloads. I don't understand the end-to-end of how resubmit is supposed to work. User space is not supposed to resubmit, but still EAGAIN is returned to user space, and drmIoctl() in user space just calls the came ioctl again. Sounds like drmIoctl() is completely wrong. Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN is used to restart the ioctl if we had to kick a thread (to make sure it doesn't hold any locks), e.g. for a blocking wait on oustanding rendering. The codepaths taken work exactly as if the thread is interrupt with a signal. In Tegra, when a job blows up, we reset the involved units, and set the pushbuffer pointer of host1x to point to the next job, and re-enable units. There's no need for anybody to resubmit anything, as kernel already has them. Yeah, that's how it works in i915.ko, too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools] tests/gem_seqno_wrap.c: include signal.h for definition of kill()
On Sun, Dec 16, 2012 at 10:38:54AM -0800, Alan Coopersmith wrote: Fixes build failure on Solaris: gem_seqno_wrap.c: In function ‘run_cmd’: gem_seqno_wrap.c:328:3: error: implicit declaration of function ‘kill’ [-Werror=implicit-function-declaration] Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Applied, thanks. -Daniel --- tests/gem_seqno_wrap.c |1 + 1 file changed, 1 insertion(+) diff --git a/tests/gem_seqno_wrap.c b/tests/gem_seqno_wrap.c index 2b92cb8..f881245 100644 --- a/tests/gem_seqno_wrap.c +++ b/tests/gem_seqno_wrap.c @@ -40,6 +40,7 @@ #include sys/wait.h #include limits.h #include wordexp.h +#include signal.h #include i915_drm.h #include intel_bufmgr.h -- 1.7.9.2 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 6:07 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 28 Sep 2012 17:44:27 +0200 Luc Verhaegen l...@skynet.be wrote: On Fri, Sep 21, 2012 at 11:35:12AM +0200, Luc Verhaegen wrote: On Sun, Aug 12, 2012 at 03:50:16PM +0200, Luc Verhaegen wrote: Hi, The FOSDEM organizers have sent out a call for devrooms. FOSDEM this year is on the weekend of the 2nd and 3rd of February 2013. After the success of this formula last year, where, for the first time ever, we had a properly filled devroom schedule when the deadline hit, i am going to re-apply the same formula: * By the 28th of september, i need 6 committed speakers, otherwise i will not apply for a DevRoom. 6 people need to apply for a talk slot who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. This definitely means: * Don't knowingly plan anything else for this weekend. * Come to FOSDEM even if your corporation does not fund you (though feel free to contact the board individually for funding) * Make sure that you are allowed to travel to the shengen area in february. * Catastrophies excluded of course. Such catastrophies include things like train-derailments and such, but explicitely excludes hangovers :p * Scheduling based on timeliness of application: the earlier you apply, the better slot you get. * FOSDEMs final deadline for the full schedule is likely around 15th of january 2013. But do not count on that deadline, we will only do hourly slots, to keep people from running around between devrooms like headless chickens. Only 12-16 slots will be available, first come, first serve. I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 I hope we get a nice devroom like we had last time. That new building we were in was really amazing, even though it took a while before all FOSDEM visitors found it. Thanks, Luc Verhaegen. Just a heads up guys, we have a week left and not a single speaker yet! Given the timing of XDC and the FOSDEM deadines, this is not too surprising, but still, with XDC2012 in its final day it is high time that we start thinking about FOSDEM. I will later on shout at people here in the room too :) All we need now is people who will definitely come to FOSDEM, and who are willing to talk in the DevRoom. If a vague idea of a topic is already known, then great, but this is not necessary yet. I now put up a preliminary wiki page at wiki.x.org/wiki/fosdem2013, add yourself to the list there. Thanks, Luc Verhaegen. Final reminder: the deadline is tonight. So far there are three speakers who lined up, and my feeling is that Matthieu and Marc lined up just so that the deadline and requirement will be met. So only a single person is intending to come to fosdem and has a topic he wants to talk about. Come on guys. Surely we can do better than that. I could come up with something, maybe people would be interested in hearing about some of our recent SoC work? I'd have to see what I could get approval for, but I could probably find *something* that's not still secret. :) Ok, ok, I'll volunteer myself for another a talk about something kernel-ish. Maybe and update on drm/i915 modesettting stuff (we should be able to check off a lot of the todos from the xdc slides by then) or maybe a talk about drm/i915 testing efforts (yeah, a lot has been happening there without much publicity this year). Or something else. To make the intel roundup complete: Chris, can I volunteer you to give another stab at an updates from flatland talk? Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools 0/4] Fix build on Solaris
On Fri, Aug 24, 2012 at 02:02:00PM -0700, Alan Coopersmith wrote: With these patches, the current head of git master builds completely on Solaris 11 with gcc 4.5, and all but intel_l3_parity.c builds fine with Solaris Studio 12.3. (The __attribute__ ((__packed__)) in that file triggers an internal compiler error in Studio I need to ask the compiler group about.) Alan Coopersmith (4): Fall back to CLOCK_MONOTONIC on systems without CLOCK_MONOTONIC_RAW Rename NOPID to NO_PID to avoid conflict with Solaris NOPID flip_test: add cast to pacify Solaris Studio compiler Add --disable-nouveau option for platforms without nouveau support Applied them all, thanks a lot. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools 2/4] Rename NOPID to NO_PID to avoid conflict with Solaris NOPID
On Fri, Aug 24, 2012 at 02:52:19PM -0700, Alan Coopersmith wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/12 02:50 PM, Eric Anholt wrote: Alan Coopersmith alan.coopersm...@oracle.com writes: Solaris sys/types.h already has #define NOPID (pid_t)(-1) Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com NOPID is the ID that was in a MI_NOOP instruction, so NOP_ID would be better. Ack! NOP_ID was what danvet suggested on IRC when I asked, but then I typoed when editing the code. Sorry about that. Fixed, and shame on me for not noticing when applying ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Linaro-mm-sig] New xf86-video-armsoc DDX driver
On Mon, May 21, 2012 at 09:55:06AM +0100, Dave Airlie wrote: * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. Or go the intel glamour route and stitch together a somewhat generic 2d accel code on top of GL. That should give you reasonable (albeit likely not stellar) X render performance. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools] Move free(cmd) to after last use of cmd in intel_gpu_top
On Sat, Feb 04, 2012 at 09:05:08AM -0800, Alan Coopersmith wrote: Error: Use after free (CWE 416) Use after free of pointer 'cmd' in call to fprintf at line 496 of tools/intel_gpu_top.c in function 'main'. Previously freed at line 491 with free. [ This bug was found by the Parfait 0.4.2 bug checking tool. For more information see http://labs.oracle.com/projects/parfait/ ] Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Thanks for the patch, applied. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools v2 0/6] Convert debugger to Automake
On Mon, Jan 09, 2012 at 09:26:14PM -0800, Ben Widawsky wrote: On Fri, Jan 06, 2012 at 06:25:04PM -0500, Gaetan Nadon wrote: Version 2 improves commit messages and custom build commands Also fixed some nits in other makefiles. I checked that the binaries produced have the same size, but I'd like someone to run a sanity check on the module. I ran distcheck, out-of-source build and build from tarball. A Tested-by tag would be appreciated. I'll be away for the next few days. I'll collect review tags and I'll push the patches next week if all goes well. Gaetan Nadon (6): Debugger: convert existing makefiles to Automake. Benchmark: use correct src and build location lib: fix include directives, alphabetize sources scripts: use PYTHON primary directive for python scripts tools: use correct src and build location config: remove unused AC_DEFINE for CAIRO, LIBUDEV and GLIB Makefile.am|8 ++-- benchmarks/Makefile.am | 29 +++ configure.ac | 60 +++ debugger/Makefile.am | 27 +-- debugger/system_routine/.gitignore | 12 - debugger/system_routine/GNUmakefile.in |3 - debugger/system_routine/Makefile | 84 debugger/system_routine/Makefile.am| 42 lib/Makefile.am| 45 - scripts/Makefile.am|7 +-- tools/Makefile.am | 78 ++ 11 files changed, 174 insertions(+), 221 deletions(-) delete mode 100644 debugger/system_routine/GNUmakefile.in delete mode 100644 debugger/system_routine/Makefile create mode 100644 debugger/system_routine/Makefile.am Acked-by: Ben Widawsky b...@bwidawsk.net I've just wanted to slurp these in but stumbled over a small conflict with Alan's solaris stuff. If you have commit access, please go wild. Otherwise I could try again, but my own buildsystem-fu is barely good enough to make things compile ;-) Thanks for your awesome work, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Intel-gfx] [PATCH] Android port of intel-gpu-tools
On Tue, Jan 10, 2012 at 10:15:01AM +0530, Sateesh Kavuri wrote: Added support for Android. Changes include fixes for compilation issues related to Android using an older version of GCC compiler (ver 4.3.3) while the latest version of intel-gpu-tools confirms to GCC ver 4.5.2 (C99 standard functions), using functions like getline(). Fixed such functions, header dependencies for android and added an Android.mk file. signed-off-by: Sateesh Kavuri sateesh.kav...@intel.com A few comments - It looks like you need a completely separate makefile for android. Is there no way to let the automake tools generate that somehow? Because this simply won't scale. - There's too much ANDRIOD #ifdef'ery in the code. Either switch to a construct that works on all platforms or extract things into a little helper functions (like the get_total_ram helper that has recently been ported to Solaris). - You don't seem to touch the testsuite, and I think you want it on Andriod, too. Added xorg-devel to cc, maybe someone else has already tried this with a different package, my buildsystem fu is not up to this. Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:intel-gpu-tools 0/6] Port to Solaris
On Fri, Jan 06, 2012 at 02:37:15PM -0800, Alan Coopersmith wrote: This allows the tools to build on Solaris 11, using either gcc 4.5.2 or Solaris Studio 12.3. The tools that require the Linux debugfs don't run, but others, such as intel_gpu_top and intel_reg_dumper do work. I've tried not to break any other platforms, but haven't tested on any to confirm that. Applied. Thanks a lot for the patches. One small nitpick to annoy you: I prefer patch revision notes in the commit messages - makes it easier to check that I've applied the right version with git am ;-) Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration and packaging (reposted to .cc)
On Fri, Jan 6, 2012 at 02:41, Gaetan Nadon mems...@videotron.ca wrote: On 12-01-04 09:38 AM, Daniel Vetter wrote: On Wed, Jan 4, 2012 at 15:33, Gaetan Nadon mems...@videotron.ca wrote: On 12-01-04 04:52 AM, Daniel Vetter wrote: While I have the attention of someone versed in buildsystem-fu: intel-gpu-tools also contains a set of tests for the i915 kernel module (and the libdrm interface for it). Currently we run them with $ make test by abusing the automake test rig. Is this ok or is there a better way to do something like this? I would think so, there is support in Automake to hook test cases and in util-macros to test for things like glib and provide configure option. It is used by several modules by invoking 'make check'. I'll look into that, but I might ask a few questions as I am not familiar with video drivers. Originally we've abused make check, but that turned out to be a bad idea because make distcheck automatically runs that. And the tests check the kernel and not intel-gpu-tools itself, so that didn't make much sense. Hence we added make test with a quick hack to run make check with a different set of tests (see the test: target in tests/Makefile.am). This makes the intel-gpu-tools package confusing. It is supposed to be tools, not a hardware test suite. I don't really see a way around this. One thing I'm wondering is whether we could easily ship these tests in some form, so that users could run them from the distro package instead of grabbing the sources. Make it clear what it is: a new intel-gpu-tests package which depends on intel-gpu-tools. Some executable installed in BINDIR runs test cases installed in DATADIR. You need to provide ways to select test cases, instructions on how to report bugs with meaningful data, etc... The executable must be smart enough to not run anything on non-Intel hardware or wrong kernel, etc... This would put your test suite in the public domain and would be run by anyone. Would it be useful or just generate more work? Would distros be willing to install this? They are the ones who would initially get the bug reports from their users. X.Org has an X Test Suite in a git repo to test the protocols. http://cgit.freedesktop.org/xorg/test/xts/tree/README I did try one of the tools on my computer. The windows started shaking and the window manager eventually fell off the monitor, never to be seen again. Needless to say, I am not willing to try any test case :-( I think you've convinced me ;-) At least for the foreseeable future, the current setup seems to be good enough. Thanks a lot for your explanations patches. Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration and packaging (reposted to .cc)
On Tue, Jan 03, 2012 at 09:12:16PM -0500, Gaetan Nadon wrote: This module is hosted as an X.Org app and is published as such. This patch adds some missing packaging files and sets some basic infrastructure common to all xorg modules which saves maintenance in the long run. http://www.x.org/wiki/NewModuleGuidelines This series applies some xorg project policies and code reuse from util-macros. In some cases it reverts upgrades that were too new for the overall xorg. There were no bug fixes, things went smoothly. All the changes done are generic and have been applied/reviewed to all xorg modules. Should there be any reasons to deviate, I'd be happy to make appropriate adjustements and comments. Gaetan Nadon (10): Add mandatory COPYING file. Use standard .gitignore file and layout Man pages still showing version 1.0 in the 1.1 release Add mandatory ChangeLog and INSTALL files config: remove unrequired AM_PROG_CC_C_O config: remove duplicate AC_PROG_CC and AC_PROG__CC_99 config: use project wide xorg warnings variable config: set-up xorg automatic rebuilding rules config: the minimum version for autoconf is 2.60 config: restore the libtool minimum version to 1.5 Applied and pushed, thanks for the patches. While I have the attention of someone versed in buildsystem-fu: intel-gpu-tools also contains a set of tests for the i915 kernel module (and the libdrm interface for it). Currently we run them with $ make test by abusing the automake test rig. Is this ok or is there a better way to do something like this? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration - Part 2
On Wed, Jan 4, 2012 at 15:17, Gaetan Nadon mems...@videotron.ca wrote: On 12-01-03 09:42 PM, Eric Anholt wrote: On Mon, 02 Jan 2012 18:23:15 -0500, Gaetan Nadon mems...@videotron.ca wrote: This series applies some xorg project policies and code reuse from util-macros. In some cases it reverts upgrades that were too new for the overall xorg. There were no bug fixes, things went smoothly. Both series for updates to automake infrastructure for this project are Acked-by: Eric Anholt e...@anholt.net I think I cribbed from xf86-video-intel when I originally did this stuff, and I didn't mean for it to be gratuitously different from our other projects, as I recall. Things evolved gradually over the last 3 years to arrive at the configuration we have today. I provided explanations so the changes do not appear to be gratuitous. I noticed the system_routine configuration is rather convoluted. I prototyped a formal automake Makefile.am and it simplifies things quite a bit, all the way up to configure.ac. As it is now, the system_routine does not build from a tarball due to a missing Makefile. I'd need a little help to do a better job. I suppose sr is the system routine, how would this gets used by someone who installed the package from a distro? I am wondering which files to install from this subdir. The system_routine/debugger stuff is from Ben Widawsky. Adding him to cc so he can join the fun. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration and packaging (reposted to .cc)
On Wed, Jan 4, 2012 at 15:33, Gaetan Nadon mems...@videotron.ca wrote: On 12-01-04 04:52 AM, Daniel Vetter wrote: While I have the attention of someone versed in buildsystem-fu: intel-gpu-tools also contains a set of tests for the i915 kernel module (and the libdrm interface for it). Currently we run them with $ make test by abusing the automake test rig. Is this ok or is there a better way to do something like this? I would think so, there is support in Automake to hook test cases and in util-macros to test for things like glib and provide configure option. It is used by several modules by invoking 'make check'. I'll look into that, but I might ask a few questions as I am not familiar with video drivers. Originally we've abused make check, but that turned out to be a bad idea because make distcheck automatically runs that. And the tests check the kernel and not intel-gpu-tools itself, so that didn't make much sense. Hence we added make test with a quick hack to run make check with a different set of tests (see the test: target in tests/Makefile.am). One thing I'm wondering is whether we could easily ship these tests in some form, so that users could run them from the distro package instead of grabbing the sources. Thanks, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration and packaging (reposted to .cc)
On Wed, Jan 4, 2012 at 18:12, Matt Dew mar...@osource.org wrote: This is the same 'make check' that the tinderbox uses right? Thread: http://lists.x.org/archives/xorg-devel/2012-January/028225.html Forgive me if I'm being dumb here. My thought, on pretty much no sleep last night, is should tinderbox be using make test instead of, or in addition to, make check? No, running that only makes sense when you have and intel gpu, and even then you need a fairly recent kernel to no oops it ;-) -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH intel-gpu-tools 00/10] Upgrade module configuration and packaging (reposted to .cc)
On Wed, Jan 4, 2012 at 16:39, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 01/04/12 06:38, Daniel Vetter wrote: One thing I'm wondering is whether we could easily ship these tests in some form, so that users could run them from the distro package instead of grabbing the sources. Should distros just be shipping the entire intel-gpu-tools package, including the tests? My dream scenario is that willling guinea-pigs could run that testsuite and hence improve our testing coverage of corner-case on strange/old hw. If distros could ship the entire thing as a nice package, that might be helpful - currently you need the sources. But this is all pretty new (1.1 is the first release with anything resembling a useful set of tests). So I'm not sure how much effort this is worth and hence my quick question. -Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Mesa-dev] Reminder: FOSDEM2012 speakers due Okt 1st.
On Mon, Sep 26, 2011 at 07:21:42AM +0200, Luc Verhaegen wrote: As stated in an email sent a week and a half ago, i need 6 we will be there nomatter what speakers for FOSDEM this year before i go and talk to the FOSDEM organizers. So far we have: * Martin Peres - Nouveau * Alon Levy - Xspice * Chris Wilson - Cairo Only half the amount needed, with 5 days left. Surely we can do better than that for X/Mesa/Wayland/Anything graphics. Chris convinced me to fry myself giving a talk about cool new stuff heading towards kernel drm and how much of this is driven by the needs of SoC's. Topics could include: dma buffer sharing work by Linaro, drm overlay support, who controls a device (drm, v4l, fb?), perhaps also how tightly integrated UMA designs like Sandybridge will need better drm-core mm integration and what great stuff we could do with this. gpu scheduling also fits into here. I'll see what makes a good fit and shows best what awesome stuff is currently going on in opens source graphics. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
