FOSDEM graphics DevRoom CFP
Hi, At FOSDEM on Sunday the 4th of February, there will the 15th Graphics DevRoom. URL: https://fosdem.org/2024/ The talk topics of the graphics devroom encompass: * graphics drivers: display, 2d engines, 3d engines, at bootloader, kernel and userspace levels. * media drivers: camera/capture engines, hardware media encoders and decoders on all levels. * input drivers for bootloaders, kernels and userspace on all levels. * windowing systems (X, wayland, others) and window managers. * graphics toolkits (QT, GTK, others). * 3D and Compute APIs (OpenGL, Vulkan, DirectX, others), and 3d and game engines. * Virtual reality hardware and toolkits. * Artificial Intelligence HW acceleration. * Media encode and decode applications. And the tools needed to help configure and run the above. Like with so many DevRooms, we got a surprise half a day only, so there will have to be 8 slots of 20 minutes (with 5 minutes of setup, and 5 mins of Q) on half an hour boundaries. Submission deadline is the 10th of december, but do not count on this date, once the schedule has filled with enough solid talks, we will accept no more. You can submit your talk here: https://fosdem.org/submit FOSDEM has moved away from the clunky but known quantity that was Pentabarf to pretalx. Accounts from Pentabarf are no longer valid, and you will have to create a new account. Please put some time and effort in the title and at least abstract. FOSDEM is a massive and thoroughly organized event, which produces a printed scheduled booklet every time, and many thousand copies will be in the hands of many thousand visitors. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so please only submit talks on a subject you actually worked on. If you are unsure on whether you can come or not, perhaps you are unsure about corporate sponsorship of your travels (this is FOSDEM, why are you not there anyway?), wait with submitting your talk until you are certain that you can be present. All talks will be recorded and made available as CC-By-Sa or CC-By. The FOSDEM CoC will have to be agreed as well (https://fosdem.org/2024/practical/conduct/) If there are any issues, just email graphics-devroom-mana...@fosdem.org, where you can reach the team of graphics devroom managers, Pierre Moreau, Arek Hiler, Martin Roukala, and myself, who will also schedule and review your talk submissions. We will be keeping a keen eye on submissions and scheduling, and hope to see you all at FOSDEM. Thanks! Luc Verhaegen.
CFP FOSDEM22 Graphics DevRoom
Hi, After a hiatus in 2021, the upcoming FOSDEM will have a graphics DevRoom again. This time round on a sunday, the 6th of February 2022. As usual, the focus of this DevRoom is: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Low level toolkit stuff * Low level machine learning. * Colour management. * ... FOSDEM '22 is sadly a virtual event again. While a virtual FOSDEM lacks all the wonderful madness of a real life FOSDEM, it does have the advantage of not having to deal with travel and accomodation, the physics of humans trundling around a big university campus, or a booklet. Talks: -- Time slots will be the usual 25/50 minute talk length, you are free to fill this time up as you see fit, but you might want to reserve 5 minutes for Q I expect there to be 8h available for scheduling. Since there are no travel accomodations to deal with, and there are no people who physically need to get from one end of the ULB campus to the other, and there are no 5000+ booklets to be printed, there is no first come, first serve requirement this year round. But the other side of that coin is that talks can be hard dropped from the devroom managers' side until very late in the process if anything is not in order. Hard talk submission deadline: 30th of december, 23:59UTC. Further info on when a talk video should be finished to fit in the FOSDEM infrastructure will follow, but expect somewhere between january 16th and 23rd, 3-2 weeks before the event. Again, more details will follow. Talk submission and review panel: Arkadiusz Hiler (ivyl) Luc Verhaegen (libv) Martin Ruokala (mupuf) Successful submitters will receive an email with further information on the 31st, as it's not as if I will have anything better to do given that mini-me will have been stabbed only once by then ;) Pentabarf: -- Since FOSDEM has had to flash migrate to virtual last year, no further work was sadly done to replace or fix pentabarf, a tool originally made to create the fancy FOSDEM booklet, so its pent-up-clunkiness has to be used again, especially since it actually works :) https://penta.fosdem.org/submission/FOSDEM22 Re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password Here are the basic requirements before we consider a talk worth scheduling: On your personal page: * General: * First Name * Last Name * Nickname * Public Name * Image * Contact: * Contact email address * Biography: * Short Biography On your event page: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Persons: * Add yourself as speaker. * Abstract: * Short abstract Unlike IRL events with a booklet, you should be able to tweak this information pretty much until you are finished with your talk. That's it, hope to see your submission in penta, and your talk at FOSDEM. Luc Verhaegen.
Re: gitlab.fd.o financial situation and impact on services
On Thu, Feb 27, 2020 at 10:27:04PM +0100, 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. > > Thanks, Daniel So this cost is all about fd.o? I feel that this was not communicated to x.org members at all, when fd.o "merging" was suggested. In as far as this was a merge. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM Graphics Devroom: call for speakers.
Hi, At FOSDEM on saturday the 1st of february 2020, there will be another graphics DevRoom. URL: https://fosdem.org/2020/ The focus of this DevRoom is: * Graphics drivers: from display to media to 3d drivers, both in bootloaders, kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management, low level toolkit stuff, and other areas which i might have overlooked above are accepted. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. We have the devroom from 10:30 til 19:00, giving us 8h30, so eight 50 minute talks and one 20 minute talk are available. Talk Submission: The venerable pentabarf system will once again be used for talk submission. https://penta.fosdem.org/submission/FOSDEM20 Remember that FOSDEM is a huge, and tightly organized event with 10+k visitors, full livestreaming, and a booklet which holds the schedule. So put some effort in your talk submission and details, especially since the schedule gets locked down well before the event starts. Since this an open source community event, please refrain from turning in a talk that is purely corporate or a product commercial. Also, this is a highly technical devroom on a conference aimed at developers and advanced users, so only submit a talk on a subject you actually are involved with. Finally, if you are unsure whether you can come or not (this is FOSDEM, why are you not there anyway?), wait with submitting your talk until you know for sure. When in pentabarf, spend some time on the abstract and description, for both the event and the speaker. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. Talks are either 50 minutes or 20 minutes long, plus 5 minutes for questions. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY, sometimes minutes after your talk has finished. As for deadlines, the fosdem organizers want to have a finished schedule by the 15th of december. Don't count on this deadline: first come first serve! The worst slots will be assigned to those who come last, which could be pretty dire given that there is the traditional FOSDEM beer event the night before ;) Please try to re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password If there are any questions or issues, just poke me by email or on IRC. Necessary information: -- Below is a list of what i need to see filled in in pentabarf when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots (which are on saturday afternoon) are for the earliest submissions. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Schedule: * select your preferred talk length, either 55 or 25 minutes. * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. Remember, i will only schedule your talk after the basics are somewhat filled in (you still can change them until december 14th). I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email. That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Individuals interested in VESA memberships?
On Fri, Nov 01, 2019 at 04:06:40PM -0400, Lyude Paul wrote: > Hi! Recently I've been working with the rest of the X.Org board to try to get > X.org access to VESA memberships so that contributors that don't have an > employer who is able/willing to join VESA can potentially get access to the > various benefits of a VESA membership, such as access to DisplayPort > specifications. Since I need to gather a list of interested X.org members, I'd > like to know who all might be interested in a membership like this. There are > no costs involved, as the VESA membership we're looking at in particular comes > at no cost to us since we're a non-profit. > > The current plan is to extend VESA membership to X.Org members who > specifically request it. If you think you'd be at all interested in this, or > know any projects or contributors who would be, please feel free to respond to > this message and let me know! Is this a one time thing? Is this something that can be requested at any time or at specific, regular, intervals? Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > Due to the lack of > controversy about the candidates [...] Such a statement, when talking about election results, very much sounds like "the election committees favourite candidates won anyway, so..." pffff. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > In the interest of transparency I should mention that one person > accidentally signed up twice and voted twice. Luckily this doesn't > change the results of the election since there is more than a 6-point > gap between 4th and 5th place. We'll take this as a reminder to have a > better look at membership sign-ups. From private conversation with Stefan, i learned that the second membership application was approved between the first round of voting and the second round of voting. How many members were added between the two rounds? Is the vote on the fd.o merger counted against the first set of members, or against the second set of members. Does that not raise questions about the validity of the fd.o bylaws change? Imho, these are 3 significant irregularities with these elections and the subsequent results. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 Xorg Election Results
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote: > > It should also be noted that even though our election process as > outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows > denying candidates any points our website didn't take this into account > and forced voters to rank every candidate. Due to the lack of > controversy about the candidates we don't expect this to have had any > impact on the final results. Does this change not massively skew results? Lack of controversy has absolutely nothing to do with it. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 X.Org Foundation Election Candidates
On Thu, Mar 14, 2019 at 08:36:13PM +, Wentland, Harry wrote: > On 2019-03-12 6:49 a.m., Luc Verhaegen wrote: > > > > Are these candidates the only thing we will be voting on? > > > > You're right. The FDO question totally slipped me mind. > > We'll also be voting on the bylaw change I sent out sometime toward the end > of last year to facilitate the marriage of fdo and x.org. > > I'll send out details shortly. Cool, thanks! This way members can actually review and perhaps discuss this instead of being confrontend with this when voting for just candidates, without preparation, which could've perhaps invalidated the result. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2019 X.Org Foundation Election Candidates
On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote: > To all X.Org Foundation Members: > > The election for the X.Org Foundation Board of Directors will begin on > 14 March 2019. We have 6 candidates who are running for 4 seats. They > are (in alphabetical order): > Attached below are the Personal Statements each candidate submitted > for your consideration along with their Statements of Contribution > that they submitted with the membership application. Please review > each of the candidates' statements to help you decide whom to vote for > during the upcoming election. > > If you have questions of the candidates, you should feel free to ask them > here on the mailing list. > > The election committee will provide detailed instructions on how the voting > system will work when the voting period begins. > > Harry, on behalf of the X.Org elections committee Are these candidates the only thing we will be voting on? Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [RESEND PATCH] drm/sun4i: hdmi: Improve compatibility with hpd-less HDMI displays
On Mon, Mar 04, 2019 at 03:06:16PM +0200, Priit Laes wrote: > From: Priit Laes > > Even though HDMI connector features hotplug detect pin (HPD), there > are older devices which do not support it. For these devices fall > back to additional check on I2C bus to probe for EDID data. > > One known example is HDMI/DVI display with following edid: > > $ xxd -p display.edid > 000005a1e0030100150f0103800f05780a0f6ea05748 > 9a2610474f20010101010101010101010101010101012a08804520e0 > 0b10200040009536001800fd0034441a2403000a202020202020 > 001000310a202020202020202020202000102a4030701300 > 782d111e006b > > $ edid-decode display.edid > EDID version: 1.3 > Manufacturer: AMA Model 3e0 Serial Number 1 > Digital display > Maximum image size: 15 cm x 5 cm > Gamma: 2.20 > RGB color display > First detailed timing is preferred timing > Display x,y Chromaticity: > Red: 0.6250, 0.3398 > Green: 0.2841, 0.6044 > Blue: 0.1494, 0.0644 > White: 0.2802, 0.3105 > > Established timings supported: > 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz > Standard timings supported: > Detailed mode: Clock 20.900 MHz, 149 mm x 54 mm >640 672 672 709 hborder 0 >480 484 484 491 vborder 0 >-hsync -vsync >VertFreq: 60 Hz, HorFreq: 29478 Hz > Monitor ranges (GTF): 52-68Hz V, 26-36kHz H, max dotclock 30MHz > Dummy block > Dummy block > Checksum: 0x6b (valid) > > Now, current implementation is still flawed, as HDMI uses the > HPD signal to indicate that the source should re-read the EDID > due to change in device capabilities. With current HPD polling > implementation we would most certainly miss those notifications > as one can try just swapping two HDMI monitors really fast. > > Proper fix would be skipping the HPD pin detection and relying > on just EDID fetching and acting on its changes. HPD has been a hard requirement since DDWG came up with DVI somewhere in the late 90s. This monitor is plainly broken, and should not get an expensive i2c address polling based workaround at the driver level. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FOSDEM 2019: Graphics DevRoom: Call for speakers.
On Mon, Nov 19, 2018 at 08:17:32AM +0100, Luc Verhaegen wrote: > Hi, > > At FOSDEM on saturday the 3rd of february 2018, there will be another > graphics DevRoom. URL: https://fosdem.org/2018/ That should of course read: At FOSDEM on saturday the 2nd of february 2019, there will be another graphics DevRoom. URL: https://fosdem.org/2019/ Eejit Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM 2019: Graphics DevRoom: Call for speakers.
Hi, At FOSDEM on saturday the 3rd of february 2018, there will be another graphics DevRoom. URL: https://fosdem.org/2018/ The focus of this DevRoom is of course the same as the previous editions, namely: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, V4L, (direct)FB, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management, low level toolkit stuff, and other areas which i might have overlooked above are accepted. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. We have the devroom from 10:30 til 19:00, giving us 8h30, so eight 50 minute talkes and one 20 minute talk are available. Talk Submission: Like the last few years, the pentabarf system will be used for talk submission. https://penta.fosdem.org/submission/FOSDEM19 Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with a sliding schedule which only gets filled out on the last day. Upwards of 1 people are visiting this event, and most of them get a printed booklet or use the schedule on the FOSDEM website or an app for their phone to figure out what to watch or participate in next. So please put some effort in your talk submission and details. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, if you are unsure on whether you can come or not (this is FOSDEM, why are you not there anyway?), please wait with submitting your talk until you do. When in pentabarf, please give the abstract and description, for both the event and the speaker, some thought. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY after a few days. As for deadlines, the fosdem organizers want to have a finished schedule by the 14th of december. Don't count on this deadline: first come first serve! The worst slots will be assigned to those who come last, which could be pretty dire given that there is the traditional FOSDEM beer event the night before ;) Please try to re-use your accounts from the previous years. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password If there are any issues, just poke me here or on IRC. Necessary information: -- Below is a list of what i need to see filled in in pentabarf when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots (which are on saturday afternoon) are for the earliest submissions. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Links: * Add relevant links. The mobile phone number is the hardest requirement, so you can be contacted on-the-day when something comes up. Speakers will all receive my mobile number in return. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. Remember, i will only schedule your talk after the basics are somewhat filled in (you still can change them until december 14th). I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email. That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM 2018: Graphics DevRoom: Call for speaker.
Hi, At FOSDEM on saturday the 3rd of february 2018, there will be another graphics DevRoom. URL: https://fosdem.org/2018/ The focus of this DevRoom is of course the same as the previous editions, namely: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management, low level toolkit stuff, and other areas which i might have overlooked above are accepted. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. We have the devroom from 10:30 til 19:00, giving us 8h30, so eight 50 minute talkes and one 20 minute talk are available. Talk Submission: Like the last few years, the pentabarf system will be used for talk submission. https://penta.fosdem.org/submission/FOSDEM18 Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with a sliding schedule which only gets filled out on the last day. Upwards of 1 people are visiting this event, and most of them get a printed booklet or use the schedule on the FOSDEM website or an app for their phone to figure out what to watch or participate in next. So please put some effort in your talk submission and details. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, if you are unsure on whether you can come or not (this is FOSDEM, why are you not there anyway?), please wait with submitting your talk. Submitting a talk and then not turning up because you could not be bothered is a sure-fire way to get larted and then to never be allowed to talk again. When in pentabarf, please give the abstract and description, for both the event and the speaker, some thought. The abstract should be a shortened description, and the event abstract will sometimes even be printed directly in the booklet. BUT, on the website the abstract is immediately followed by the full description. If your abstract is fully descriptive, while terse, you might get away with just the abstract. All talks will be recorded, and will be streamed out live, and will later be made available as CC-BY after a few days. As for deadlines, the fosdem organizers want to have a finished schedule by the 15th of december. Don't count on this deadline: first come first serve! The worst slots will be assigned to those who come last, which could be pretty dire given that there is the traditional FOSDEM beer event the night before ;) Please try to re-use your accounts from the previous years, i hope that this year you can actually recycle your data. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password If there are any issues, just poke me here or on IRC. Necessary information: -- Below is a list of what i need to see filled in in pentabarf when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots (which are on saturday afternoon) are for the earliest submissions. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email address * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Links: * Add relevant links. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. Remember, i will only schedule your talk after the basics are somewhat filled in (you still can change them until december 15th). I will be keeping a keen eye on your submissions and will come back with further questions or make small fixes as needed. Feel free to poke me with any questions or anything, both on irc (libv@freenode) and on email. That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote: > On Tue, 11 Apr 2017, Luc Verhaegen <l...@skynet.be> wrote: > > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: > >> On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen <l...@skynet.be> wrote: > >> > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > >> >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen <l...@skynet.be> wrote: > >> >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> >> >> freedesktop.org has adopted a formal code of conduct: > >> >> >> > >> >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> >> >> > >> >> >> Besides formalizing things a bit more I don't think this changes > >> >> >> anything for us, we've already peer-enforced respectful and > >> >> >> constructive interactions since a long time. But it's good to > >> >> >> document > >> >> >> things properly. > >> >> >> > >> >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> >> >> started chatting with the communities their hosting, which includs > >> >> >> the > >> >> > > >> >> > "started" and "chatting"? That is very weakly formulated. > >> >> > >> >> Intentionally so ... > >> >> > >> >> >> X.org foundation board, to figure out how to fan out enforcement and > >> >> > > >> >> > This was not voted upon or even mentioned during the last board > >> >> > meeting. > >> >> > And i think the next board meeting is only in 2 days time. As such, > >> >> > this > >> >> > seems like it is not something that's officially sanctioned by the > >> >> > X.org > >> >> > foundation board, but you sure do try to make it sound like such. > >> >> > >> >> ... because it is not yet sanctioned by the board in any way. So not > >> >> exactly sure where you're reading this into my commit message, because > >> >> it wasn't my intention to make it sounds like this is sanctioned by > >> >> the xorg board officially, nor did I state that anywhere. I just said > >> >> that discussions already started to happen, that's really all there > >> >> is. > >> > > >> > Thanks for making that clear. > >> > >> Yeah I understand the confusion, since it wasn't clear that this mail > >> was written by me with my drm maintainer hat on, not me in my role as > >> xorg bod secretary. Nor me as an intel employee. I should have made > >> that clearer. > > > > I was not confused about that, especially since you mentioned the board. > > But this clearly was not something already approved by the X.org > > foundation board. > > Since there is a lot of "it" and "this" in both your and Daniel's > messages, without clarifying what you're both actually talking about, I > think for clarity it should be noted that, AFAIU, the decision to adopt > the CoC is up to the freedesktop.org admins, not the X.org board, and > the discussion about enforcing is to take place between the two. It's the way in which this is being done that makes me very weary of this code of conduct. It seems like a very unilateral move, quite likely by just a single person. There is no record of any prior discussion, not with the affected projects, not on any mailing list, not on the irc channels where i am on (and i doubt it is logged publicly anywhere). This commit Daniel Vetter just posted comes the closest to any discussion, wayland never was so lucky. This feels like the typical freedesktop.org move, and i am quite allergic to those as i and the projects i have been involved in have been the target of such unilateral decisions several times. I see the mentioning of the X.org foundation board here as an attempt to give this surprise Code of Conduct some gravitas which it didn't deserve, as it was far too easily debunked. The board of directors never voted on this, and i would like to see the emails of the discussion prior to this mentioning here. If there were any, they were not before the surprise wayland commit. I would welcome such a code of conduct though, if it had been the result of an honest, open and transparent community discussion. But that's not something i have often seen at freedesktop.org. And i have a feeling as to how it will be applied and who or what projects it will be applied to, and how transparent that process will be. If people would be interested in seeing this Code of Conduct retro-actively, i might have a few cases that i would want to bring up, though. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 3:30 PM, Luc Verhaegen <l...@skynet.be> wrote: > > On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > >> On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen <l...@skynet.be> wrote: > >> > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> >> freedesktop.org has adopted a formal code of conduct: > >> >> > >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> >> > >> >> Besides formalizing things a bit more I don't think this changes > >> >> anything for us, we've already peer-enforced respectful and > >> >> constructive interactions since a long time. But it's good to document > >> >> things properly. > >> >> > >> >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> >> started chatting with the communities their hosting, which includs the > >> > > >> > "started" and "chatting"? That is very weakly formulated. > >> > >> Intentionally so ... > >> > >> >> X.org foundation board, to figure out how to fan out enforcement and > >> > > >> > This was not voted upon or even mentioned during the last board meeting. > >> > And i think the next board meeting is only in 2 days time. As such, this > >> > seems like it is not something that's officially sanctioned by the X.org > >> > foundation board, but you sure do try to make it sound like such. > >> > >> ... because it is not yet sanctioned by the board in any way. So not > >> exactly sure where you're reading this into my commit message, because > >> it wasn't my intention to make it sounds like this is sanctioned by > >> the xorg board officially, nor did I state that anywhere. I just said > >> that discussions already started to happen, that's really all there > >> is. > > > > Thanks for making that clear. > > Yeah I understand the confusion, since it wasn't clear that this mail > was written by me with my drm maintainer hat on, not me in my role as > xorg bod secretary. Nor me as an intel employee. I should have made > that clearer. I was not confused about that, especially since you mentioned the board. But this clearly was not something already approved by the X.org foundation board. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 03:24:04PM +0200, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 3:12 PM, Luc Verhaegen <l...@skynet.be> wrote: > > On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > >> freedesktop.org has adopted a formal code of conduct: > >> > >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ > >> https://www.freedesktop.org/wiki/CodeOfConduct/ > >> > >> Besides formalizing things a bit more I don't think this changes > >> anything for us, we've already peer-enforced respectful and > >> constructive interactions since a long time. But it's good to document > >> things properly. > >> > >> Note: As Daniel Stone mentioned in the announcement fd.o admins > >> started chatting with the communities their hosting, which includs the > > > > "started" and "chatting"? That is very weakly formulated. > > Intentionally so ... > > >> X.org foundation board, to figure out how to fan out enforcement and > > > > This was not voted upon or even mentioned during the last board meeting. > > And i think the next board meeting is only in 2 days time. As such, this > > seems like it is not something that's officially sanctioned by the X.org > > foundation board, but you sure do try to make it sound like such. > > ... because it is not yet sanctioned by the board in any way. So not > exactly sure where you're reading this into my commit message, because > it wasn't my intention to make it sounds like this is sanctioned by > the xorg board officially, nor did I state that anywhere. I just said > that discussions already started to happen, that's really all there > is. Thanks for making that clear. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Document code of conduct
On Tue, Apr 11, 2017 at 08:48:15AM +0200, Daniel Vetter wrote: > freedesktop.org has adopted a formal code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for us, we've already peer-enforced respectful and > constructive interactions since a long time. But it's good to document > things properly. > > Note: As Daniel Stone mentioned in the announcement fd.o admins > started chatting with the communities their hosting, which includs the "started" and "chatting"? That is very weakly formulated. > X.org foundation board, to figure out how to fan out enforcement and This was not voted upon or even mentioned during the last board meeting. And i think the next board meeting is only in 2 days time. As such, this seems like it is not something that's officially sanctioned by the X.org foundation board, but you sure do try to make it sound like such. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: add SimpleDRM driver
On Thu, Aug 04, 2016 at 06:58:55PM +0200, Noralf Trønnes wrote: > > I didn't read the binding document[1], which I should have done. > If simpledrm claims to be compatible with simple-framebuffer I assume it > should support the entire binding doc which includes clocks, regulators > and having the node under /chosen. > I will lift the necessary code from simplefb.c and put it in the next > version. Smashing, repeat of a massive pain avoided, thanks :) > The binding doc also mentions an optional display phandle property, but I > can't find any reference to this in simplefb.c. By that time i had long, long given up on this, i think Hans de Goede, who is a few orders of magnitude more patient than me, should know. He valiantly whipped this thing through back then. Luc Verhaegen.
[PATCH 0/2] drm: add SimpleDRM driver
On Thu, Aug 04, 2016 at 05:44:23PM +0200, David Herrmann wrote: > Hi > > On Thu, Aug 4, 2016 at 5:34 PM, Luc Verhaegen wrote: > > Do we really want to recreate a 400+ email thread again, or are we > > capable of learning from the past? > > No we don't. And no-one intends to. I am fully aware of the discussion > that introduced the clock-dependencies to simplefb, and I gladly > accept patches that add such support to SimpleDRM. Did anyone say > otherwise? This series adds initial support for the devices _we_ know > and can test (which is x86 and RPi, in my case). If someone wants > support for more devices, please send patches. Why does this have to > be included (or even discussed) as part of this submission? You're right, it does not have to be included until there is a usecase. But on the otherhand i have become pretty allergic to this as that other discussion was completely useless and pointless and stemmed only from the fact that people had been kidding themselves all along that simplefb was going to be simple and not would need anything extra. If we can avoid fooling ourselves to the same extent as we did before, then putting this off until there is a real usecase is perfectly fine by me. If not, just add this trivial generic addition straight from an existing example. Luc Verhaegen.
[PATCH 0/2] drm: add SimpleDRM driver
On Thu, Aug 04, 2016 at 05:08:43PM +0200, Daniel Vetter wrote:
> On Thu, Aug 04, 2016 at 04:15:25PM +0200, Luc Verhaegen wrote:
> > On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
> > >
> > > I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> > > framebuffer and producing this node:
> > >
> > > framebuffer at 1e887000 {
> > > compatible = "simple-framebuffer";
> > > reg = <0x1e887000 0x36c600>;
> > > format = "r5g6b5";
> > > width = <1824>;
> > > height = <984>;
> > > stride = <3648>;
> > > status = "okay";
> > > };
> > >
> > > I have only tested with fbcon and modetest (XR24,RG16).
> >
> > Please do not make the same mistake as simplefb in making this purely a
> > rpifb. Know that you will need some power and clock management for
> > properly free devices that do not depend on a binary only RTOS which
> > does _everything_ behind our backs.
> >
> > Cfr this useless, endless and ridiculous discussion:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279071.html
>
> simpledrm isn't a real driver, but only meant to be used to drive the
> firmware framebuffer in early boot until a real driver takes over. It's a
> replacement really for all the various uefi/vesa/whatever fbdev drivers.
> Full reliance on the firmware very much intended.
> -Daniel
In the sunxi case, that firmware was u-boot, and the clocks were
properly declared and then also properly disabled, which meant the
display block got disabled.
Is simpledrm only an intermediate solution until the real driver is
loaded? What stops it from providing a rudimentary display driver for
the whole uptime of the machine? What stops the kernel from disabling
the clocks while the supposed real driver is not fully loaded yet?
Do we really want to recreate a 400+ email thread again, or are we
capable of learning from the past?
Luc Verhaegen.
[PATCH 0/2] drm: add SimpleDRM driver
On Thu, Aug 04, 2016 at 04:03:18PM +0200, Noralf Trønnes wrote:
>
> I have tested simpledrm on a Raspberry Pi B+ with U-boot setting up the
> framebuffer and producing this node:
>
> framebuffer at 1e887000 {
> compatible = "simple-framebuffer";
> reg = <0x1e887000 0x36c600>;
> format = "r5g6b5";
> width = <1824>;
> height = <984>;
> stride = <3648>;
> status = "okay";
> };
>
> I have only tested with fbcon and modetest (XR24,RG16).
Please do not make the same mistake as simplefb in making this purely a
rpifb. Know that you will need some power and clock management for
properly free devices that do not depend on a binary only RTOS which
does _everything_ behind our backs.
Cfr this useless, endless and ridiculous discussion:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/279071.html
Luc Verhaegen.
EXTENDED: 2016 X.Org Board of Directors Elections Nomination period is NOW
On Wed, Mar 16, 2016 at 04:03:08PM +1000, Peter Hutterer wrote: > We had a number of last-minute nominations and this did not give all nominees > the chance to respond to the nominations. Sheepish Verhaegen.
FOSDEM16: Graphics DevRoom: call for speakers.
Hi, At FOSDEM on sunday 31st of january 2016, there will be another graphics DevRoom. URL: https://fosdem.org/2016/ At first, I wanted to skip another year (like in 2011), as speaker turn-out was disgracefully low last year. But when i heard from some usual speaker suspects earlier this month (the first time anyone asked me about a FOSDEM16 devroom btw), followed by the fact that the devroom request deadline was sheduled a month later than the last few years, i did end up filing, but this time for a single day only. Claiming two days would simply not have been fair towards all the other projects that usually get rejected (FOSDEM typically rejects half the requests, leading to only about 25 devrooms in parallel). Anyway... The focus of this DevRoom is of course the same as the last few years, namely: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management, low level toolkit stuff, and other areas which i might have overlooked above are accepted. Slots are 50 minutes long, and scheduled hourly. This partly to avoid confusion and people running all over the place all the time. As a speaker, you do not have to fill your whole hour, gaps are never wasted time. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. The amount of slots is currently not known yet, but there are only 8 slots available, so act quickly. Talk Submission: Like the last few years, the pentabarf system will be used for talk submission. It is not perfect from a devroom organizer and talk submitters usability point-of-view, but the new interface is not fully implemented yet, and the fosdem organizers have reverted to the old one for this year. It is however workable and it ended up working out pretty well these last few years. https://penta.fosdem.org/submission/FOSDEM16 Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with a sliding schedule which only gets filled out on the last day. Upwards of 8000 people are visiting this event, and most of them get a printed booklet or use the schedule on the FOSDEM website or an app for their phone to figure out what to watch or participate in next. So please put some effort in your talk submission and details. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, if you are unsure on whether you can come or not (this is FOSDEM, why are you not there anyway?), please wait with submitting your talk. Submitting a talk and then not turning up because you could not be bothered is a sure-fire way to get larted and then to never be allowed to talk again. Also, all talks will be recorded, and will be made available as CC-BY after a bit of time. Since we have only a single day devroom, we probably will not end up being streamed live. As for deadlines, the fosdem organizers are doing their booklet differently again, and they need to have the schedule finished by the 18th of december. Given that there are only 8 slots, i trust that this will not be an issue this year. Don't count on this deadline: first come first serve! There are perhaps only 8 slots. And the worst slots will be assigned to those who come last. Do you really want to talk on sunday at 9:00 when people are still in zombie mode after 2 nights at the delirium bar, if they are here at all? Use your account from last year, so you can try to recycle some of your data from last year. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password Necessary information: -- Below is a list of what i need to see filled in when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots are for the earliest submissions and there are only 8 slots. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Links: * Add relevant links. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. Remember, i will only schedule your talk after the basics are somewhat filled in (you still can change them until december 18th). That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen.
[PATCH v2 1/7] drm/vc4: Add devicetree bindings for VC4.
On Tue, Aug 18, 2015 at 02:54:02PM -0700, Eric Anholt wrote: > VC4 is the GPU (display and 3D) subsystem present on the 2835 and some > other Broadcom SoCs. > ... > +Broadcom VC4 GPU > + > +The VC4 device present on the Raspberry Pi includes a display system > +with HDMI output and the HVS scaler for compositing display planes. Is this a direct hw driver implementation, banging registers, or is this talking to the os/firmware/binary blob running on the videocore dsp? Luc Verhaegen.
FOSDEM15: Graphics DevRoom: call for speakers.
On Tue, Jan 13, 2015 at 01:14:17PM +0100, Thierry Reding wrote: > On Tue, Dec 09, 2014 at 03:39:26PM +0100, Luc Verhaegen wrote: > > On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote: > > > Hi, > > > > > > At FOSDEM on the 31st of january and the 1st of February 2015, there > > > will be another graphics DevRoom. URL: https://fosdem.org/2015/ > > > > > Slots will be handed out on a first come, first serve basis. The best > > > slots will go to those who apply the earliest. The amount of slots is > > > currently not known yet, but i expect there to be around 16 available (8 > > > on each day), so act quickly. > > > > > As for deadlines, i hope to have a pretty much complete schedule between > > > christmas and the new year. The rockhard printed schedule deadline is > > > probably January 9th, after that you will not be featured in the booklet > > > and you will have a lot less visitors. I will hopefully be able to lock > > > down entries and descriptions after that date. > > > > It's been more than 2 months since the original email, it's less than > > two months away from the event, and one month away from what usually is > > the deadline for the booklet. File your talk now, while there are still > > some useful slots available. > > > > Also, for those who have filed already but who have left their abstracts > > open, please get those filed in ASAP. Your talk will be only be ordered > > in when at least the basics are provided. > > Hi Luc, > > I realize I'm terribly late, but it took quite some time to get travel > arranged. Looking at the schedule there still seem to be some free > slots. Does it make sense to still submit a talk? I was asked to give > one on atomic modesetting from a driver developer's perspective. > > Thierry Yes, but be quick, the hard booklet deadline is thursday evening. I will not be accepting talks past tomorrow evening. Luc Verhaegen.
FOSDEM15: Graphics DevRoom: call for speakers.
On Thu, Oct 02, 2014 at 07:44:57PM +0200, Luc Verhaegen wrote: > Hi, > > At FOSDEM on the 31st of january and the 1st of February 2015, there > will be another graphics DevRoom. URL: https://fosdem.org/2015/ > Slots will be handed out on a first come, first serve basis. The best > slots will go to those who apply the earliest. The amount of slots is > currently not known yet, but i expect there to be around 16 available (8 > on each day), so act quickly. > As for deadlines, i hope to have a pretty much complete schedule between > christmas and the new year. The rockhard printed schedule deadline is > probably January 9th, after that you will not be featured in the booklet > and you will have a lot less visitors. I will hopefully be able to lock > down entries and descriptions after that date. It's been more than 2 months since the original email, it's less than two months away from the event, and one month away from what usually is the deadline for the booklet. File your talk now, while there are still some useful slots available. Also, for those who have filed already but who have left their abstracts open, please get those filed in ASAP. Your talk will be only be ordered in when at least the basics are provided. Thanks, Luc Verhaegen.
FOSDEM15: Graphics DevRoom: call for speakers.
Hi, At FOSDEM on the 31st of january and the 1st of February 2015, there will be another graphics DevRoom. URL: https://fosdem.org/2015/ The focus of this DevRoom is of course the same as last year, namely: * Graphics drivers: from display to media to 3d drivers, both in kernel or userspace. Be it part of DRM, KMS, (direct)FB, V4L, Xorg, Mesa... * Input drivers: kernel and userspace. * Windowing systems: X, Wayland, Mir, directFB, ... * Even colour management and other areas which i might have overlooked above are accepted. Slots are 50 minutes long, and scheduled hourly. This partly to avoid confusion and people running all over the place all the time. As a speaker, you do not have to fill your whole hour, gaps are never wasted time. Slots will be handed out on a first come, first serve basis. The best slots will go to those who apply the earliest. The amount of slots is currently not known yet, but i expect there to be around 16 available (8 on each day), so act quickly. Talk Submission: Like last year, the pentabarf system will be used for talk submission. It is not perfect from a devroom organizer and talk submitters usability point-of-view, but the fosdem organizers are working on it. It is however workable and it ended up working out pretty well last year. https://penta.fosdem.org/submission/FOSDEM15 Remember that FOSDEM is not like XDC, it's not some 50 odd people meeting with a sliding schedule which only gets filled out on the last day. Upwards of 8000 people are visiting this event, and most of them get a printed booklet or use the schedule on the FOSDEM website or an app for their phone to figure out what to watch or participate in next. So please put some effort in your talk submission and details. Since this an open source community event, please refrain from turning in a talk that is a pure corporate or product commercial. Also, if you are unsure on whether you can come or not (this is FOSDEM, why are you not there anyway?), please wait with submitting your talk. Submitting a talk and then not turning up because you could not be bothered is a sure-fire way to get larted and then to never be allowed to talk again. As for deadlines, i hope to have a pretty much complete schedule between christmas and the new year. The rockhard printed schedule deadline is probably January 9th, after that you will not be featured in the booklet and you will have a lot less visitors. I will hopefully be able to lock down entries and descriptions after that date. Don't count on this deadline: first come first serve! There are perhaps only 16 slots. And the worst slots will be assigned to those who come last. Do you really want to talk on saturday at 10:00 when people are still in zombie mode after the beer event, if they are there at all? Use your account from last year, so you can try to recycle some of your data from last year. If you have forgotten your password, then you can reset it here: https://penta.fosdem.org/user/forgot_password Necessary information: -- Below is a list of what i need to see filled in when you apply for a devroom before i consider it a valid submission. Remember: first come, first serve. The best slots are for the earliest submissions and there are only around 16 slots. On your personal page: * General: * First and last name * Nickname * Image * Contact: * email * mobile number (this is a very hard requirement as there will be no other reliable form of emergency communication on the day) * Description: * Abstract * Description Create an event: * On the General page: * Event title * Event subtitle. * Track: Graphics Devroom * Event type: Lecture (talk) or Meeting (BoF) * Persons: * Add yourself as speaker. * Description: * Abstract: * Full Description * Links: * Add relevant links. Everything else can be ignored or will be filled in by me or the FOSDEM organizers. That's about it. Hope to see you all at FOSDEM :) Luc Verhaegen.
FOSDEM14: Graphics DevRoom: Deadline approaching fast.
On Tue, Jan 07, 2014 at 02:22:00AM +0100, Luc Verhaegen wrote: > Hi, > > There are still 5 slots open for the FOSDEM graphics DevRoom, and the > deadline is this friday, the 10th. Get a move on. > > If you have requested an account reset with me before, but if you then > haven't bothered filing a talk, you do NOT have a slot. Please file a > talk ASAP to still secure a place. > > For more information on how to file for a devroom, read the email sent > back in october: > http://lists.x.org/archives/xorg-devel/2013-October/038185.html > > Luc Verhaegen. There are still 3 slots open. This is your final chance to get a talk in the FOSDEM 2014 graphics DevRoom. Monday night (13th), the schedule will be locked down and no further talks or events will be accepted. Luc Verhaegen.
FOSDEM14: Graphics DevRoom: Deadline approaching fast.
Hi, There are still 5 slots open for the FOSDEM graphics DevRoom, and the deadline is this friday, the 10th. Get a move on. If you have requested an account reset with me before, but if you then haven't bothered filing a talk, you do NOT have a slot. Please file a talk ASAP to still secure a place. For more information on how to file for a devroom, read the email sent back in october: http://lists.x.org/archives/xorg-devel/2013-October/038185.html Luc Verhaegen.
FOSDEM14: Graphics DevRoom: call for speakers.
it. Hope to see you all at FOSDEM :) Luc Verhaegen.
[Linaro-mm-sig] CDF discussions at FOSDEM
On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote: > Hello, > > On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote: > > > > I've sent a mail to the FOSDEM organizers to request a hacking room for a > > couple of hours Sunday. I'll let you know as soon as I get a reply. > > Just a quick follow-up. I've received information from the FOSDEM staff, > there > will be hacking rooms that can be reserved (on-site only) for 1h slots. They > unfortunately won't have projectors, as they're not meant for talks. > > Another option would be to start early on Saturday, the X.org room is > reported > as beeing free from 9am to 11am. > > -- > Regards, > > Laurent Pinchart As the organizer of the X.org devroom, i would have to state that the latter is impossible. I tend to do a bit of room set-up, like put in some power bars (a limited amount this year, as i only have been given one day and it simply is not worth putting in the cabling for 100 sockets, and dragging all that kit over from Nuremberg, for just a single day) and some other things. I need one hour at least for that on saturday morning. DevRooms are also not supposed to open before 11:00 (which is already a massive improvement over 2011 and the years before, where i was happy to be able to put the cabling in at 12:00), and i tend to first get a nod of approval from the on-site devrooms supervisor before i go in and set up the room. So use the hackingroom this year. Things will hopefully be better next year. Luc Verhaegen.
Re: [Linaro-mm-sig] CDF discussions at FOSDEM
On Tue, Jan 29, 2013 at 12:27:15PM +0100, Laurent Pinchart wrote: Hello, On Monday 21 January 2013 13:43:27 Laurent Pinchart wrote: I've sent a mail to the FOSDEM organizers to request a hacking room for a couple of hours Sunday. I'll let you know as soon as I get a reply. Just a quick follow-up. I've received information from the FOSDEM staff, there will be hacking rooms that can be reserved (on-site only) for 1h slots. They unfortunately won't have projectors, as they're not meant for talks. Another option would be to start early on Saturday, the X.org room is reported as beeing free from 9am to 11am. -- Regards, Laurent Pinchart As the organizer of the X.org devroom, i would have to state that the latter is impossible. I tend to do a bit of room set-up, like put in some power bars (a limited amount this year, as i only have been given one day and it simply is not worth putting in the cabling for 100 sockets, and dragging all that kit over from Nuremberg, for just a single day) and some other things. I need one hour at least for that on saturday morning. DevRooms are also not supposed to open before 11:00 (which is already a massive improvement over 2011 and the years before, where i was happy to be able to put the cabling in at 12:00), and i tend to first get a nod of approval from the on-site devrooms supervisor before i go in and set up the room. So use the hackingroom this year. Things will hopefully be better next year. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: > > 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. > > Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen.
FOSDEM2013: DevRoom or not?
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. Luc Verhaegen.
Re: FOSDEM2013: DevRoom or not?
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. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FOSDEM2013: DevRoom or not?
On Fri, Sep 28, 2012 at 05:44:27PM +0200, Luc Verhaegen wrote: 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. Luc Verhaegen. After a bit of a scramble, we now have 7.5 speakers confirmed, and two pending budget/approval (which do not count towards the limit). I have therefor sent off the request to the organizers, there is little doubt that we will once again get a nice devroom next year :) We still have, i hope (depends on what the FOSDEM organizers have left for us), 6 slots fully open: first come first serve, and the earlier bird gets the nicer slot! Thanks all, especially those who stepped up already. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM2013: DevRoom or not?
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.
Re: FOSDEM2013: DevRoom or not?
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM2013: DevRoom or not?
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.
FOSDEM2013: DevRoom or not?
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. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm: Add plane event
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote: > DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is > for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to > provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl > can change the framebuffer of plane but user can't know completion of > changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT is > added, we can also do pageflip of a plane. This whole discussion brings up some related topics. * Base planes, the actual main fb, should be treated as planes and fit in the same infrastructure. I see little point in treating these things seperately, just different capabilities (but not always). * How to convey plane capabilities to userspace. The current situation is not really satisfactory. For FBs, which currently can be assigned to either a CRTC (base plane) or a plane, you have to crystal ball in userspace to guess what the layout for a given colourformat for a given plane should be, and the possible differences in layout between the different planes are not taken into account the current FB creation handlers. Apart from colour format for actual planes you get no information up front and, if you are lucky, you get treated with -EINVAL at the time of setting the plane. In Xvideo, the Xv client got to ask the X server what the actual layout had to be for a given colour format at given dimensions. This made sure that not yet another copy, or further swizzling was needed before the hw could display it. Then there is scaling, position and z-ordering, again, no information up front, sometimes you get -EINVAL, sometimes some values are silently altered, sometimes it just messes up. This needs to be solved differently. It is clear that not all information can be provided beforehand to suit all hardware and all situations, but most of what is listed above can be provided beforehand, part of it as plane resources, and part in a separate FB query which provides plane, colour format and dimensions, and which then returns sizes/offsets and pitches. That what cannot be standardized can then still be a silent alteration or -EINVAL. Luc Verhaegen.
[RFC PATCH] drm: Add plane event
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote: > On 04/18/2012 04:36 PM, Daniel Vetter wrote: >> Last time around I've discussed with people we've ended up with 2 new >> ioctls: >> >> - atomic modeset, to configure the output state on more than one crtc at >>the same time. This is useful to get pll assignement, memory bandwidth >>constrains and similar stuff right. This ioctl is synchronous. A >>testmode can be used to inquire the driver whether the proposed mode >>actually works. This could be used for gui interfaces to automatically >>grey out unsupportable configurations, e.g. if you have 3 crtc but on 2 >>pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs. >> >> - an atomic pageflip. This one would be like the current pageflip ioclt, >>i.e. run asynchronously and deliver a drm event upont completion. The >>idea is that compositors can use this to make flicker-free compositition >>with drm planes possible. I think we want drivers to be able to indicate >>which crtc properties they can switch with this ioctl, e.g. I expect >>some yuv->rbg color space properties might not work. All the changes >>should be applied on the same vblank, obviously. > Why an atomic pagefilp? How is this different from an atomic modeset > where only fbs change? Can't drm frmwrk "optimize" this like SETCRTC > does today with base/full modeset helpers? Buffering. When you are doing triple buffering and need to update addresses, which should be flipped at next vblank, you do not want to go through a massive amount of state handling. I do not agree with SETCRTC though. The CRTC is the entity that serializes, that has the actual modeline set, that might allow rotation and/or scaling all of the planes and cursors (to the extent that these are not planes) that are put into it. Planes are the actual FB and possible overlays. It is the planes that do colour conversion and whatnot (pitch), might allow for z-ordering, individual scaling and rotation, and which might not need to be full screen. It is these elements that take in buffer addresses and should do page flipping. You might have to artificially split out the base plane and CRTC for your hardware, and have some code duplication or multiple uses of the same functions. Now look at the relative probability of each of the actions: * The frequency of altering the mode (on the crtc) is very low. * The frequency of altering the planes is/should already a lot higher when you are using the likes of wayland or the android hw compositor. * The frequency of page flipping is very high. This means that there should be (at least) three separate actions: * page flipping: buffers -> planes at next vblank, for a list of buffer(s) and plane tuples. * setplanes: colour format, position, scaling, ordering, rotation, color key, crtc adherance, _plus_ the above. * actual modeset, which handles the CRTC and out to the monitor and whatnot, which should also include the above. With appropriate helper functions combining these events should not be hard as you move down the list. As someone who has spent quite a lot of time with Xvideo in the past (and pretty much the only guy still around who wrote up ReputImage support for his graphics driver), i am glad that we have buffer management today, and we should use that to the max and cut down on duplicated and errorprone state tracking. Luc Verhaegen.
Re: [RFC PATCH] drm: Add plane event
On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote: On 04/18/2012 04:36 PM, Daniel Vetter wrote: Last time around I've discussed with people we've ended up with 2 new ioctls: - atomic modeset, to configure the output state on more than one crtc at the same time. This is useful to get pll assignement, memory bandwidth constrains and similar stuff right. This ioctl is synchronous. A testmode can be used to inquire the driver whether the proposed mode actually works. This could be used for gui interfaces to automatically grey out unsupportable configurations, e.g. if you have 3 crtc but on 2 pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs. - an atomic pageflip. This one would be like the current pageflip ioclt, i.e. run asynchronously and deliver a drm event upont completion. The idea is that compositors can use this to make flicker-free compositition with drm planes possible. I think we want drivers to be able to indicate which crtc properties they can switch with this ioctl, e.g. I expect some yuv-rbg color space properties might not work. All the changes should be applied on the same vblank, obviously. Why an atomic pagefilp? How is this different from an atomic modeset where only fbs change? Can't drm frmwrk optimize this like SETCRTC does today with base/full modeset helpers? Buffering. When you are doing triple buffering and need to update addresses, which should be flipped at next vblank, you do not want to go through a massive amount of state handling. I do not agree with SETCRTC though. The CRTC is the entity that serializes, that has the actual modeline set, that might allow rotation and/or scaling all of the planes and cursors (to the extent that these are not planes) that are put into it. Planes are the actual FB and possible overlays. It is the planes that do colour conversion and whatnot (pitch), might allow for z-ordering, individual scaling and rotation, and which might not need to be full screen. It is these elements that take in buffer addresses and should do page flipping. You might have to artificially split out the base plane and CRTC for your hardware, and have some code duplication or multiple uses of the same functions. Now look at the relative probability of each of the actions: * The frequency of altering the mode (on the crtc) is very low. * The frequency of altering the planes is/should already a lot higher when you are using the likes of wayland or the android hw compositor. * The frequency of page flipping is very high. This means that there should be (at least) three separate actions: * page flipping: buffers - planes at next vblank, for a list of buffer(s) and plane tuples. * setplanes: colour format, position, scaling, ordering, rotation, color key, crtc adherance, _plus_ the above. * actual modeset, which handles the CRTC and out to the monitor and whatnot, which should also include the above. With appropriate helper functions combining these events should not be hard as you move down the list. As someone who has spent quite a lot of time with Xvideo in the past (and pretty much the only guy still around who wrote up ReputImage support for his graphics driver), i am glad that we have buffer management today, and we should use that to the max and cut down on duplicated and errorprone state tracking. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: Add plane event
On Wed, Apr 18, 2012 at 01:31:59PM +0900, Joonyoung Shim wrote: DRM_MODE_PLANE_EVENT is similar to DRM_MODE_PAGE_FLIP_EVENT but it is for a plane. The setplane ioctl (DRM_IOCTL_MODE_SETPLANE) needs to provide the event such as DRM_MODE_PAGE_FLIP_EVENT. The setplane ioctl can change the framebuffer of plane but user can't know completion of changing the framebuffer of plane via event. If DRM_MODE_PLANE_EVENT is added, we can also do pageflip of a plane. This whole discussion brings up some related topics. * Base planes, the actual main fb, should be treated as planes and fit in the same infrastructure. I see little point in treating these things seperately, just different capabilities (but not always). * How to convey plane capabilities to userspace. The current situation is not really satisfactory. For FBs, which currently can be assigned to either a CRTC (base plane) or a plane, you have to crystal ball in userspace to guess what the layout for a given colourformat for a given plane should be, and the possible differences in layout between the different planes are not taken into account the current FB creation handlers. Apart from colour format for actual planes you get no information up front and, if you are lucky, you get treated with -EINVAL at the time of setting the plane. In Xvideo, the Xv client got to ask the X server what the actual layout had to be for a given colour format at given dimensions. This made sure that not yet another copy, or further swizzling was needed before the hw could display it. Then there is scaling, position and z-ordering, again, no information up front, sometimes you get -EINVAL, sometimes some values are silently altered, sometimes it just messes up. This needs to be solved differently. It is clear that not all information can be provided beforehand to suit all hardware and all situations, but most of what is listed above can be provided beforehand, part of it as plane resources, and part in a separate FB query which provides plane, colour format and dimensions, and which then returns sizes/offsets and pitches. That what cannot be standardized can then still be a silent alteration or -EINVAL. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Closed source userspace graphics drivers with an open source kernel component
On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote: > Luc, can you please take your corporate bullshit out of this? I can > assume you know Dave personally and should be clearly aware that he's > everything but a corporate drone. Yes, with mails like this he clearly shows that he isn't a corporate drone. Luc Verhaegen.
Closed source userspace graphics drivers with an open source kernel component
On Fri, Jul 02, 2010 at 08:23:27PM +1000, Dave Airlie wrote: > > > > They own quite a lot of the IP in the 3D core, having bought it from > AMD, you can see the CP packets and PM4 stuff just like in radeon. Aha, imageon indeed, cool! I doubt that you know the conditions of this sale. This might just be about waiting for Qualcomm to sort things out, or it might be about a licensing issue still. We just cannot know this. > I know who Jordan is well from AMD, and I've stated this isn't a > Qualcomm only thing, but companies need to understand that putting > stuff into the kernel is part of a bargain, where you get the benefits > of all the work everyone has done on the kernel and they get the > benefits of being able to do stuff with the code you provide, only > giving us a half arsed interface to the hw and hiding all the good > stuff in userspace isn't accepting this bargain. You can say what you > like about liceneses and legalese but Linus picked the GPL for this > sort of everyone gives what they get. Sure, but you still slammed, and this affected in first order mostly Qualcomm, instead of stating that you simply do not want to be involved. > They'll keep shipping closed stuff, just like they are now. Are you > going to reverse engineer the userspace drivers, so people who care > about open and free software platforms can use these drivers? (or have > you already signed NDAs saying you can't). Why should we maintain a > bunch of kernel code, when they are hiding away all the really useful > stuff that people could improve. Maintaining this exact code is not _your_ job, and you should've stated just that. > I would, some points > (a) Red Hat is the company I work for. > (b) Red Hat doesn't really care about this stuff at all. > (c) I'm the kernel maintainer for far longer that I worked for Red > Hat, I also work a lot with Intel at Red Hat and I've told them the > same thing, and VIA and now I'm stating it so I don't have to restate > individually to every company again. You will need to restate this every time anyway, unless you somehow manage to get your rather daunting and loud statement to be the first thing such corporations management people at linux.com, which is what people type in their browser first. But maybe you might want to adjust your message. > You don't understand what being a kernel maintainer is do you? at all? Heh, i could make a really nasty statement here, but i wont. > Wierd I'm still seeing new docs being produced and old docs being > updated, not as fast as I'd like but I understand how many people > there is working on it and I'd rather we also got fixes for all the > current stuff done as well. Hrm, i only see _very_ old docs getting updated, and none produced. I still have docs which are pretty ready to be shipped (from 2007), under uncertain legal status (the ati game was fun!), which were never made public. I am sure that bridgman, gave you these docs too, but under even more shady circumstances. > The code doesn't exist, there is no userspace code to be the > documents, if you read what I said, documents would be a good start in > lieu of code, but code is perfectly fine. > Imagintaion technologies seriously? they've never ever taken one step > towards opening anything, I don't think this statement is suddenly > going to jumpstart them. > Maybe you should disclose what NDAs you currently are under and who > pays your bills, since you accuse me of Red Hat mind-control. Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm sure you knew. > I'm not sure how the ARM market would benefit from having no userspace > 3D drivers just like the x86 market, if you actually were normal you'd > realise the ARM people are trying to screw the market just like the > desktop people, to save themselves some money, but maybe working on > closed drivers has twisted you. Ah, so you did know. As a free software graphics driver developer there is little option left but to go straight to the ARM world, at least things have potential to move there still. Well, unless the efforts there, like the one that triggered your mail, are thwarted too, like with your mail. Luc Verhaegen.
Closed source userspace graphics drivers with an open source kernel component
ce (assuming ARM ever solves that > issue). I think that by now you should have realized that this is not how it works for things as complex as graphics drivers. If, for instance, you hadn't been given a wildcard by your employer, you would never have gone close to AMD hw unless for some spare time poking and occasional bugfixing. Also, before you throw this up: for nouveau, documentation would take part of the fun, the attraction and excitement, away. Provide docs, and then only a few very industrious people will remain, and they will also get weary after a while, or they get hired by someone to continue their work, bringing us right back to the corporate world. Now, it is interesting how you now are demanding documentation. When did recent and relevant hw documentation happen for ATI? This pretty much died together when the ATI<->SuSE relationship died, as the cooperation of SuSE and AMD is how documentation was forced out of ATI in the first place, and ATI more and more found ways to get rid of this responsibility, or overhead as bridgman would most likely name it. I think it even should be possible to find statements of you and/or alex, and definitely bridgman, where it is claimed that for ATI, "the code is the documentation". If you are backing this reasoning for ATI, what is wrong with this code being the documentation for Qualcomm? This point about documentation at least does not seem very credible coming from you, with your history, especially with respect to the ATI story. > I've also noticed a trend to just reinvent the whole wheel instead of > writing a drm/kms driver and having that as the API, again maintainer > nightmares are made of this. Heh, in some of these cases, not having looked at this code in detail yet, such code predates kms, and drm might not have provided what was needed. Not wanting to completely diminish the responsibility of qualcomm (or the other companies who are working or are forced to work like this), you might want to think about providing stable and fitting infrastructure, not just stating that something is how _you_ are doing it and declaring that the law. Next to that, the IP heavy part that cannot be released (yet?) might be some blob that is used on both linux, windows, ximbian, etc. The concept of talking to some os independent blob through some painful and ever-shifting layer is not that alien even to you, with your staunch defending of ATIs AtomBIOS over more direct modesetting. Also, from where i sit, you complaining about people reinventing the wheel does bring me some bitter amusement. As a conclusion: With you having sent this mail, guess what the guys at qualcomm, and most likely imagination technologies and ARM as well (i think we can already discount nvidia -- they are far too adept at producing solid closed source drivers -- to desktop users satisfaction too), will do next? We already squandered the free software desktop (on x86), and part of the responsibility for that is with the graphics hw support (and the radeon versus radeonhd story shows nicely how to go about squandering such things). What i see here is that you clearly want to go down a similar street with the now blossoming ARM market. Thanks alot, Luc Verhaegen.
Re: Closed source userspace graphics drivers with an open source kernel component
On Fri, Jul 02, 2010 at 08:23:27PM +1000, Dave Airlie wrote: They own quite a lot of the IP in the 3D core, having bought it from AMD, you can see the CP packets and PM4 stuff just like in radeon. Aha, imageon indeed, cool! I doubt that you know the conditions of this sale. This might just be about waiting for Qualcomm to sort things out, or it might be about a licensing issue still. We just cannot know this. I know who Jordan is well from AMD, and I've stated this isn't a Qualcomm only thing, but companies need to understand that putting stuff into the kernel is part of a bargain, where you get the benefits of all the work everyone has done on the kernel and they get the benefits of being able to do stuff with the code you provide, only giving us a half arsed interface to the hw and hiding all the good stuff in userspace isn't accepting this bargain. You can say what you like about liceneses and legalese but Linus picked the GPL for this sort of everyone gives what they get. Sure, but you still slammed, and this affected in first order mostly Qualcomm, instead of stating that you simply do not want to be involved. They'll keep shipping closed stuff, just like they are now. Are you going to reverse engineer the userspace drivers, so people who care about open and free software platforms can use these drivers? (or have you already signed NDAs saying you can't). Why should we maintain a bunch of kernel code, when they are hiding away all the really useful stuff that people could improve. Maintaining this exact code is not _your_ job, and you should've stated just that. I would, some points (a) Red Hat is the company I work for. (b) Red Hat doesn't really care about this stuff at all. (c) I'm the kernel maintainer for far longer that I worked for Red Hat, I also work a lot with Intel at Red Hat and I've told them the same thing, and VIA and now I'm stating it so I don't have to restate individually to every company again. You will need to restate this every time anyway, unless you somehow manage to get your rather daunting and loud statement to be the first thing such corporations management people at linux.com, which is what people type in their browser first. But maybe you might want to adjust your message. You don't understand what being a kernel maintainer is do you? at all? Heh, i could make a really nasty statement here, but i wont. Wierd I'm still seeing new docs being produced and old docs being updated, not as fast as I'd like but I understand how many people there is working on it and I'd rather we also got fixes for all the current stuff done as well. Hrm, i only see _very_ old docs getting updated, and none produced. I still have docs which are pretty ready to be shipped (from 2007), under uncertain legal status (the ati game was fun!), which were never made public. I am sure that bridgman, gave you these docs too, but under even more shady circumstances. The code doesn't exist, there is no userspace code to be the documents, if you read what I said, documents would be a good start in lieu of code, but code is perfectly fine. Imagintaion technologies seriously? they've never ever taken one step towards opening anything, I don't think this statement is suddenly going to jumpstart them. Maybe you should disclose what NDAs you currently are under and who pays your bills, since you accuse me of Red Hat mind-control. Oh, i now work for basysKom, a contractor for, amongst others, nokia, which i'm sure you knew. I'm not sure how the ARM market would benefit from having no userspace 3D drivers just like the x86 market, if you actually were normal you'd realise the ARM people are trying to screw the market just like the desktop people, to save themselves some money, but maybe working on closed drivers has twisted you. Ah, so you did know. As a free software graphics driver developer there is little option left but to go straight to the ARM world, at least things have potential to move there still. Well, unless the efforts there, like the one that triggered your mail, are thwarted too, like with your mail. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Closed source userspace graphics drivers with an open source kernel component
On Fri, Jul 02, 2010 at 06:15:35AM -0400, Christoph Hellwig wrote: Luc, can you please take your corporate bullshit out of this? I can assume you know Dave personally and should be clearly aware that he's everything but a corporate drone. Yes, with mails like this he clearly shows that he isn't a corporate drone. Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Mesa3d-dev] [PATCH] Provide dri shared library building and SDK installation.
d system changes and mesa internal dependencies than anything else. This quite effectively proves the long term feasibility of this SDK. Why do you like to see these "new" interfaces spelled out completely? You said yourself that this was just one big mess. It is not my job to go in and clean up this mess that was created over the timeframe of more than a decade, just to get you to see a clean API that you now apparently require before this very pragmatic patch can go in. What i do here is identify those bits of the API that are required for building the dri drivers externally. This is a very first step, one that does not hamper anyones abilities to work the way they are used to. If this does not evolve anymore because, as you said, you consider mesa/dri deprecated, then so be it, then this SDK is the actual API. How does this patch limit you in anyway? Could it be that you are more afraid of getting a ball rolling here, of being unable to mute existing demand with "impossible" (which, tbh, i haven't heard from you personally, but have heard frequently from others), than you are of this actual patch. To conclude, you basically state here that: a) you do not want any mesa internal APIs to become slightly more public as that might make it less easy to completely throw things around. b) mesa/dri is a mess that you consider deprecated, and you do not want the world to see what sort of a mess it became over the space of more than a decade and due to a). c) mesa/dri has no API, even though the fact that there are a dozen or so drivers using this "No-API" kind of points the other way. What i want to state is: a) Everyone needs the ability to get driver updates and bugfixes easily and painlessly, and the creation of an SDK, by formalizing existing library boundaries and headers can solve that with very little pain and only build system additions. b) It doesn't matter whether mesa/dri is considered deprecated, that just makes it easier to maintain this SDK. c) It doesn't matter what the api looks like, this patch is just a very pragmatic approach where we just pick what the drivers require. We actually might learn a thing or two here which might make gallium better software in future, without forcing a completely new mode of working on anybody today. If i had done the same work for mesa/gallium there would be a lot more protest, even though there are less drivers, and the existing API is supposed to be much much clean and beautiful, which inherently makes that a lot more practical than what i have now done for mesa/dri. Luc Verhaegen.
[PATCH] Provide dri shared library building and SDK installation.
Patch cherry-picked from my dri-sdk-7.8 branch against current head (edb5253dfa). An earlier full build through of all drivers (except nouveau, i will play with its expansive libdrm dependencies later) showed it to be an exact match still. This patch, while not harming or hampering anything or anyone, gives us the ability to maintain and build DRI drivers out of tree for those so inclined. Build system additions only. No adverse effects. Everybody wins. I intend to provide changes as needed, I hope to at least manage to maintain released versions in the long term. For those wanting a test run, please check out the 7.8 version of the SDK and the drivers in my cgit.freedesktop.org repos. Luc Verhaegen.
[PATCH] Provide dri shared library building and SDK installation.
Signed-off-by: Luc Verhaegen --- Makefile | 13 +++ src/mesa/Makefile | 61 +++- src/mesa/drivers/dri/common/Makefile | 80 +++ src/mesa/drivers/dri/common/libmesadricommon.pc.in |9 ++ src/mesa/drivers/dri/swrast/Makefile | 10 ++ src/mesa/libmesadri.pc.in |9 ++ src/mesa/sources.mak | 103 7 files changed, 283 insertions(+), 2 deletions(-) create mode 100644 src/mesa/drivers/dri/common/Makefile create mode 100644 src/mesa/drivers/dri/common/libmesadricommon.pc.in create mode 100644 src/mesa/libmesadri.pc.in diff --git a/Makefile b/Makefile index 411130b..5c20b77 100644 --- a/Makefile +++ b/Makefile @@ -15,6 +15,19 @@ default: $(TOP)/configs/current all: default +dri-sdk: + cd src/mesa/ && $(MAKE) dri-sdk + +dri-sdk-install: + cd src/mesa/ && $(MAKE) dri-sdk-install + +dri-swrast: + cd src/mesa/drivers/dri/swrast && $(MAKE) dri-swrast + +dri-swrast-install: + cd src/mesa/drivers/dri/swrast && $(MAKE) dri-swrast-install + + doxygen: cd doxygen && $(MAKE) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index 8c0ebf8..9f5aec4 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -36,6 +36,17 @@ libmesa.a: $(MESA_OBJECTS) $(GLSL_LIBS) libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) @ $(MKLIB) -o mesagallium -static $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) +libmesadri.so.$(MESA_VERSION): asm_subdirs glsl_builtin $(MESA_OBJECTS) + $(MKLIB) -major $(MESA_MAJOR) -minor $(MESA_MINOR) \ + -patch $(MESA_TINY) -o mesadri $(MESA_OBJECTS) + +libmesadri: libmesadri.so.$(MESA_VERSION) + +libmesadricommon: + (cd drivers/dri/common && $(MAKE)) || exit 1 + +dri-sdk: libmesadri libmesadricommon + # Make archive of gl* API dispatcher functions only libglapi.a: $(GLAPI_OBJECTS) @ $(MKLIB) -o glapi -static $(GLAPI_OBJECTS) @@ -60,7 +71,17 @@ asm_subdirs: ## # GLSL built-in library -glsl_builtin: + +../glsl/pp/libglslpp.a: + (cd ../glsl/pp/ && $(MAKE)) || exit 1 ; + +../glsl/cl/libglslcl.a: + (cd ../glsl/cl/ && $(MAKE)) || exit 1 ; + +../glsl/apps/compile: ../glsl/pp/libglslpp.a ../glsl/cl/libglslcl.a ../glsl/apps/compile.c + (cd ../glsl/apps/ && $(MAKE) compile) || exit 1 ; + +glsl_builtin: ../glsl/apps/compile (cd shader/slang/library && $(MAKE)) || exit 1 ; @@ -145,13 +166,49 @@ install-dri: default cd drivers/dri && $(MAKE) install +libmesadri_pcedit = sed \ + -e 's, at INSTALL_DIR@,$(INSTALL_DIR),' \ + -e 's, at INSTALL_LIB_DIR@,$(INSTALL_LIB_DIR),' \ + -e 's, at INSTALL_INC_DIR@,$(INSTALL_INC_DIR),' \ + -e 's, at VERSION@,$(MESA_MAJOR).$(MESA_MINOR).$(MESA_TINY),' + +libmesadri.pc: libmesadri.pc.in + $(libmesadri_pcedit) $< > $@ + +install-libmesadricommon: + cd drivers/dri/common && $(MAKE) install + +$(DESTDIR)$(INSTALL_INC_DIR)/mesa/%: $(subst $(DESTDIR)$(INSTALL_INC_DIR)/mesa/,,$@) + $(INSTALL) -d $(dir $@) + $(INSTALL) -m 644 $(subst $(DESTDIR)$(INSTALL_INC_DIR)/mesa/,,$(dir $@))$(notdir $@) $(dir $@) + +install-libmesadri-headers: $(addprefix $(DESTDIR)$(INSTALL_INC_DIR)/mesa/,$(LIBMESADRI_HEADERS)) + # since glproto's internal/glcore.h is vastly out of sync anyway. + $(INSTALL) -d $(DESTDIR)$(INSTALL_INC_DIR)/GL + $(INSTALL) -d $(DESTDIR)$(INSTALL_INC_DIR)/GL/internal + $(INSTALL) -m 644 $(TOP)/include/GL/internal/glcore.h $(DESTDIR)$(INSTALL_INC_DIR)/GL/internal + +install-libmesadri: libmesadri.so libmesadri.pc install-libmesadri-headers + $(INSTALL) -d $(DESTDIR)$(INSTALL_LIB_DIR) + $(INSTALL) -d $(DESTDIR)$(INSTALL_LIB_DIR)/pkgconfig + $(MINSTALL) libmesadri.so.$(MESA_VERSION) $(DESTDIR)$(INSTALL_LIB_DIR) + $(MINSTALL) libmesadri.so.$(MESA_MAJOR) $(DESTDIR)$(INSTALL_LIB_DIR) + $(MINSTALL) libmesadri.so $(DESTDIR)$(INSTALL_LIB_DIR) + $(INSTALL) -m 644 libmesadri.pc $(DESTDIR)$(INSTALL_LIB_DIR)/pkgconfig + +dri-sdk-install: install-libmesadri install-libmesadricommon # Emacs tags tags: etags `find . -name \*.[ch]` $(TOP)/include/GL/*.h -clean: +libmesadri-clean: + -rm -f libmesadri.so* + -rm -f libmesadri.pc + cd drivers/dri/common && $(MAKE) clean + +clean: libmesadri-clean -rm -f */*.o -rm -f */*/*.o -rm -f depend depend.bak libmesa.a libglapi.a libmesagallium.a diff --git a/src/mesa/drivers/dri/common/Makefile b/src/mesa/drivers/dri/common/Makefile new file mode 100644 index 000..c4db042 --- /dev/null +++ b/src/mesa/drivers/dri/common/Makefile @@ -0,0 +1,80 @@ +TOP = ../../../../.. +include $(TOP)/configs/current +
