Re: Why does libinput randomly calls my touchpad "SynPS/2 Synaptics" or "Synaptics TM2722-001"?
Just so folks know: I happen to have experience with this part of the linux kernel (it's not a libinput bug) so I handled this offlist and redirected Ottavio to the right place to ask for support ♥ On Tue, 2024-04-23 at 15:12 +0100, Ottavio Caruso wrote: > Hi, > > $ sudo X -version > > X.Org X Server 1.21.1.7 > X Protocol Version 11, Revision 0 > Current Operating System: Linux t440 6.1.0-20-amd64 #1 SMP > PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 > Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-20-amd64 > root=UUID=42a17f43-89bb-4523-952f-b8d97bcb4a30 ro quiet > xorg-server 2:21.1.7-3+deb12u7 (https://www.debian.org/support) > Current version of pixman: 0.42.2 > > $ xinput --version > xinput version 1.6.3 > XI version on server: 2.4 > > > > On my old-ish Thinkpad T440, libinput alternatively calls my touchpad > "SynPS/2 Synaptics" or "Synaptics TM2722-001". > > $ grep Synaptics /var/log/messages > Nov 26 09:12:38 t440 kernel: [18070.908478] psmouse serio1: > synaptics: > serio: Synaptics pass-through port at isa0060/serio1/input0 > Nov 26 09:12:38 t440 kernel: [18070.947812] input: SynPS/2 Synaptics > TouchPad as /devices/platform/i8042/serio1/input/input35 > Nov 26 20:33:19 t440 kernel: [27221.274488] rmi4_f01 rmi4-00.fn01: > found > RMI device, manufacturer: Synaptics, product: TM2722-001, fw id: 0 > Nov 26 20:33:19 t440 kernel: [27221.314747] input: Synaptics TM2722- > 001 > as /devices/pci:00/:00:1f.3/i2c-0/0-002c/rmi4- > 00/input/input39 > Nov 27 19:28:05 t440 kernel: [ 6.327297] psmouse serio1: > synaptics: > serio: Synaptics pass-through port at isa0060/serio1/input0 > Nov 27 19:28:05 t440 kernel: [ 6.366655] input: SynPS/2 Synaptics > TouchPad as /devices/platform/i8042/serio1/input/input2 > > This without even rebooting or suspending the laptop. > > I have some scripts that disable or enable the touchpad (especially > when > I use the mouse) and I have to use tricks to accommodate this. > > Why does this happen in the first place? How can I troubleshoot it? > > Thanks. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: Wayland compatibility layer
Hi, I saw this and had a couple questions. When you say "wayland compatibility layer" I assumed at first this was for some reason a duplicate of nested compositors but I think I may have misunderstood. Is this basically the opposite of Xwayland, e.g. allowing X to act as a wayland compositor with twelveto11 as the translation layer? On Thu, 2022-10-20 at 13:08 +0800, Po Lu wrote: > Over the past several months, I and some other individuals wrote a > Wayland compositor that runs on common X setups. The code can be found > here: > > https://sourceforge.net/projects/twelveto11/ > Also JFYI - seeing as this is a freedesktop/x.org adjacent project you're more then welcome to use our gitlab instance if you'd like something a bit more accessible to host your code on. > It should be a more or less complete implementation of the important > parts of the Wayland protocol. Buffer transforms are currently missing, > but that's because I can't wrap my head around how they work. If DRI3 > is extended to allow creating Xv video, it would allow implementing YUV > image formats without a dependency on GL. > > The only major inefficiency I can think of is that buffer contents get > copied at least once, to the offscreen storage of the toplevel window, > which is then composited by the X compositing manager. Buffer-flipping > does not yet work well for fullscreen opaque surfaces, as that requires > some additions to the Composite extension here to work well: > > https://lists.x.org/pipermail/xorg-devel/2022-October/058918.html > > Please try it out and report any crashes or bugs that you may come > across. Thanks in advance. Patches are also welcome, and the code > should be well commented and structured, but please keep in mind the > coding standards (which happen to overlap greatly with the GNU ones): > https://www.gnu.org/prep/standards. > -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Requests For Proposals for hosting XDC 2023 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2023. Since XDC 2022 is being held in North America this year, XDC 2023 is expected to be in Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2022*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Best regards, Lyude Paul On behalf of X.org -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
XDC 2022: Registration & Call for Presentations still open!
Hello! This is just a reminder that the CFP for XDC in 2022 is still open! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
XDC 2022: Registration & Call for Presentations still open!
Hello! This is just a reminder that the CFP for XDC in 2022 is still open! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
XDC 2022: Registration & Call for Presentations still open!
Hello! This is just a reminder that the CFP for XDC in 2022 is still open! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org
XDC 2022: Registration & Call for Proposals now open!
Hello! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org
Requests For Proposals for hosting XDC 2023 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2023. Since XDC 2022 is being held in North America this year, XDC 2023 is expected to be in Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of *September 1st, 2022*. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. Best regards, Lyude Paul On behalf of X.org
2022 X.Org Foundation Election vote results
The Board of Directors election and the vote on the By-laws concluded at 23:59 UTC on 18 April 2022. There are 80 current Members of the X.Org Foundation, and 52 Members cast votes. This is a 65.0% turn out. In the election of the Directors to the Board of the X.Org Foundation, the results were that Emma Anholt, Alyssa Rosenzweig, Mark Filion and Ricardo Garcia were elected for two year terms. The old full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark Filion, Manasi D Navare, Keith Packard, Lyude Paul, Daniel Vetter, Harry Wentland The new full board is: Emma Anholt, Samuel Iglesias Gonsálvez, Mark Filion, Manasi D Navare, Alyssa Rosenzweig, Lyude Paul, Daniel Vetter, and Ricardo Garcia The full election results were as follows: Option | Rank 1 | Rank 2 | Rank 3 | Rank 4 | Rank 5 | Rank 6 | Final Score Emma Anholt | 21 | 16 | 4 | 1 | 5 | 5 | 240 Alyssa Rosenzweig | 4 | 10 | 17 | 7 | 11 | 3 | 188 Mark Filion | 8 | 12 | 7 | 10 | 5 | 10 | 186 Ricardo Garcia | 9 | 4 | 5 | 17 | 10 | 7 | 172 Lucas Stach | 4 | 5 | 14 | 9 | 11 | 9 | 163 Shashank Sharma | 6 | 5 | 5 | 8 | 10 | 18 | 143 Lyude Paul, on behalf of the X.Org elections committee
2022 X.org Foundation Election Candidates
To all X.Org Foundation Members: The election for the X.Org Foundation Board of Directors will begin on 04 April 2022. We have 6 candidates who are running for 4 seats. They are: Emma Anholt Shashank Sharma Ricardo Garcia Mark Filion Lucas Stach Alyssa Rosenzweig To be found in the link below 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. https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ 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. Lyude Paul, on behalf of the X.Org elections committee
2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 31 March 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Lyude Paul, on behalf of the X.Org elections committee
2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding the election schedule and nominating process to the membership shortly. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is 31 March 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ Lyude Paul, on behalf of the X.Org elections committee
2022 X.Org Board of Directors Elections Nomination period is NOW
The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 20th March 2022. The slate of candidates will be published 28th March 2022 and candidate Q will begin then. The deadline for Xorg membership applications and renewals is 31st March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
2022 X.Org Board of Directors Elections timeline extended, Request for nominations
We are seeking nominations for candidates for election to the X.org Foundation Board of Directors. However, as we presently do not have enough nominations to start the election - the decision has been made to extend the timeline by 2 weeks. Note this is a fairly regular part of the elections process. The new deadline for nominations to the X.org Board of Directors is 23:59 UTC on 20th March 2022. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 20th March 2022. The slate of candidates will be published 28th March 2022 and candidate Q will begin then. The deadline for Xorg membership applications and renewals is 31st March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
2022 X.Org Board of Directors Elections Nomination period is NOW
We are seeking nominations for candidates for election to the X.Org Foundation Board of Directors. All X.Org Foundation members are eligible for election to the board. Nominations for the 2022 election are now open and will remain open until 23:59 UTC on 06 March 2022. The Board consists of directors elected from the membership. Each year, an election is held to bring the total number of directors to eight. The four members receiving the highest vote totals will serve as directors for two year terms. The directors who received two year terms starting in 2021 were Lyude Paul, Samuel Iglesias Gonsálvez, Manasi D Navare and Daniel Vetter. They will continue to serve until their term ends in 2023. Current directors whose term expires in 2022 are Emma Anholt, Keith Packard, Harry Wentland and Mark Filion. A director is expected to participate in the fortnightly IRC meeting to discuss current business and to attend the annual meeting of the X.Org Foundation, which will be held at a location determined in advance by the Board of Directors. A member may nominate themselves or any other member they feel is qualified. Nominations should be sent to the Election Committee at elections at x.org. Nominees shall be required to be current members of the X.Org Foundation, and submit a personal statement of up to 200 words that will be provided to prospective voters. The collected statements, along with the statement of contribution to the X.Org Foundation in the member's account page on http://members.x.org, will be made available to all voters to help them make their voting decisions. Nominations, membership applications or renewals and completed personal statements must be received no later than 23:59 UTC on 6th March 2022. The slate of candidates will be published 14 March 2022 and candidate Q will begin then. The deadline for Xorg membership applications and renewals is 17 March 2022. Cheers, Lyude Paul, on behalf of the X.Org BoD
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
[Important!] 2022 X.Org Foundation Membership deadline for voting in the election
The 2022 X.Org Foundation elections are rapidly approaching. We will be forwarding instructions on the nomination process to membership in the near future. Please note that only current members can vote in the upcoming election, and that the deadline for new memberships or renewals to vote in the upcoming election is March 17th 2022 at 23:59 UTC. If you are interested in joining the X.Org Foundation or in renewing your membership, please visit the membership system site at: https://members.x.org/ You can find the current election schedule here: https://www.x.org/wiki/BoardOfDirectors/Elections/2022/ Lyude Paul, On behalf of the X.Org elections committee
Re: Help needed for EVoC/GSoC/Outreachy
Hi everyone! I got some questions from someone that made me realize that there's a couple of things that I forgot to mention here that might be useful for folks to know regarding being a mentor: * "Who decides what project and what student?" It's up to the student to come up with ideas for what they want to work on, although we will occasionally have a list of potential project ideas that students are welcome to use or draw inspiration from. Since X.org participates as a foundation, pretty much any of the projects under the X.org umbrella are allowed to do this if they're willing to come up with mentors. As for who the mentors are, that's really all just up to who's volunteering for it on a given project. As for how we decide what students we accept, that decision is usually made based off the quality of their project proposal along with whether a student seems self-sufficient enough to accomplish said project. Most students who come to us with a project idea already typically fall into this category. The final decision for this is typically made by the student's proposed mentor and/or our volunteer GSoC/Outreachy/EVoC admin. * "I assume this is international?" X.org tries to make our student outreach programs as international as possible. GSoC covers most of the world, but there are definitely some areas it doesn't cover - which is why we've ran EVoC in the past, so that students in areas that wouldn't be eligible for GSoC would still have a chance at participating in a project. Outreachy also helps fill this gap, as I don't believe they have the same kind of international restrictions that GSoC does. * What is the expected result, a grading? Yes. On Wed, 2021-07-14 at 16:32 -0400, Lyude Paul wrote: > Hi! As some of you might already be aware, after helping out X.org > project the previous years with regards to student outreach, Trevor > decided to retire from this position in hopes that someone else will be > able to step up and take on these responsibilities. As such, we're > trying to find people who would be willing to volunteer their time to > help out with getting us involved once again in student outreach > programs. > > In the past, X.org has been active in the GSoC program, occasionally > Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to > shorten the amount of time allocated for a student to work on their > project. This unfortunately posed some problems for > X.org/freedesktop.org as a lot of the potential work that would have > been good for us to have students working on wouldn't really fit within > the new GSoC timeframe. While it's certainly possible that there will be > projects that come up in the future which do fit into this new timeline, > we think it'd be a good idea to step up our involvement again with > Outreachy where the program is a good bit more flexible then GSoC. We've > also had pretty good experience working with the Outreachy candidates > we've had in the past. > > The other main topic of discussion is around the fact that our own > program, EVoC, hasn't really had anyone available to volunteer to help > run it for a while now. For those who aren't aware, EVoC is a program > similar to Google Summer of Code that X.org started running with much > more relaxed requirements then GSoC/Outreachy in order to help fill the > gaps for any exceptional cases with students who would otherwise be left > out by the requirements for GSoC/Outreachy. Typically though, EVoC is > usually considered the last resort after a student has tried getting > into GSoC/Outreachy. > > So, the two biggest things that we need are: > * Admin volunteer(s) > * Mentors, mentors, mentors! We really need these the most. > > So, what responsibilities would being an admin for this entail? > > * Fielding questions from potential GSoC/EVoC/Outreachy participants. > Most of these students are just looking for simple details of how > these programs work and are looking for project ideas. Responding to > these inquiries is mostly just a matter of pointing students to > various pages on our wiki or replying with form/stock replies. Most of > the students at this phase expect to be handed a project and a mentor, > and therefore end up learning that they will need to come up with > their own project and mentor. > * For the small handful of students that make it to the next phase and > figure out a project idea, they then need to find a mentor. Usually > the admin will help out by taking a look at who proposed the project > idea, and/or looking through commit messages and mailing list history > to try to find someone who would be a good fit and willing to mentor > the student. Sometimes this happens quickly, and sometimes it requires > poking a lot of
Help needed for EVoC/GSoC/Outreachy
Hi! As some of you might already be aware, after helping out X.org project the previous years with regards to student outreach, Trevor decided to retire from this position in hopes that someone else will be able to step up and take on these responsibilities. As such, we're trying to find people who would be willing to volunteer their time to help out with getting us involved once again in student outreach programs. In the past, X.org has been active in the GSoC program, occasionally Outreachy, and our own EVoC program. As of 2021 though, GSoC decided to shorten the amount of time allocated for a student to work on their project. This unfortunately posed some problems for X.org/freedesktop.org as a lot of the potential work that would have been good for us to have students working on wouldn't really fit within the new GSoC timeframe. While it's certainly possible that there will be projects that come up in the future which do fit into this new timeline, we think it'd be a good idea to step up our involvement again with Outreachy where the program is a good bit more flexible then GSoC. We've also had pretty good experience working with the Outreachy candidates we've had in the past. The other main topic of discussion is around the fact that our own program, EVoC, hasn't really had anyone available to volunteer to help run it for a while now. For those who aren't aware, EVoC is a program similar to Google Summer of Code that X.org started running with much more relaxed requirements then GSoC/Outreachy in order to help fill the gaps for any exceptional cases with students who would otherwise be left out by the requirements for GSoC/Outreachy. Typically though, EVoC is usually considered the last resort after a student has tried getting into GSoC/Outreachy. So, the two biggest things that we need are: * Admin volunteer(s) * Mentors, mentors, mentors! We really need these the most. So, what responsibilities would being an admin for this entail? * Fielding questions from potential GSoC/EVoC/Outreachy participants. Most of these students are just looking for simple details of how these programs work and are looking for project ideas. Responding to these inquiries is mostly just a matter of pointing students to various pages on our wiki or replying with form/stock replies. Most of the students at this phase expect to be handed a project and a mentor, and therefore end up learning that they will need to come up with their own project and mentor. * For the small handful of students that make it to the next phase and figure out a project idea, they then need to find a mentor. Usually the admin will help out by taking a look at who proposed the project idea, and/or looking through commit messages and mailing list history to try to find someone who would be a good fit and willing to mentor the student. Sometimes this happens quickly, and sometimes it requires poking a lot of people - and occasionally, there might not always be a mentor to be found. * If we have a student, project, and mentor then the next step is having the student write up a proposal. Many students start out with over-simplified proposals, so a lot of this work is just gently nudging students and getting them to refine their work items into a week-by-week synopsis. There's usually a good bit of back and forth with the student's proposal, and occasionally the mentor may be involved with this step. * The admin then works with the student to come up with a timeline for their work, taking into account any vacation time the student may have, along with coordinating the frequency/type of meetings that will happen between the student and the mentor. If the mentor is unable to attend all of these meetings, it's usually up to the admin to check in with the student to see how they are progressing and potentially provide them tips if they get stuck. As for being a mentor, it's pretty much as simple as it sounds: you work with students who have projects to help familiarize them with the project at hand, help them out wherever needed, check in on their progress, and guide them along the way towards reaching their project goal along with grading their work. Please help spread the word on this, and contact anyone you know who might be involved with this! We'll be happy to provide more information on how you can get started. Remember, folks like myself wouldn't be in this community without projects like GSoC :). -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Freenode fallout
Hi everyone! As I'm sure most of you heard by now, Freenode's staff has had a falling out and it's been recommended by their staff that projects consider the network a hostile entity. I won't go into the details here, but those who are interested can read up here: https://lwn.net/Articles/856543/ At the moment, the vast majority of IRC channels for various Freedesktop and X.org projects currently reside on Freenode. While the X.org foundation doesn't have any official policies on IRC hosting, because of how frequently IRC is used by various projects in our community we on the board decided to make a non-binding recommendation on an IRC network we think would be good to move to. We're also looking at ways to provide some resources to help channels move en masse. We hope this will enable interested projects to migrate to the same new IRC network in order to ensure they're all in the same place. After considering Libera and OFTC as options, the board settled on recommending OFTC. The primary reason for this is because OFTC is associated with our parent foundation SPI, and has a long and well known history of involvement with the open source community. As well, the board believes OFTC's current Governance model is a lot more clear then Libera's. -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've asked me a question, are waiting for a review/merge on a patch, etc. and I haven't responded in a while, please feel free to send me another email to check on my status. I don't bite! ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Requests For Proposals for hosting XDC2021 are now open
Hello everyone! The X.org board is soliciting proposals to host XDC in 2021. Since XDC2020 is being held virtually this year, we've decided to host in either North America or Europe. However, the board is open to other locations, especially if there's an interesting co-location with another conference. Of course though, due to the ongoing COVID-19 pandemic it's not yet clear whether or not it will be possible to host XDC2021 in person. Because of this, we would like to make it clear that sponsors should prepare for both the possibility of an in person conference, and the possibility of a virtual conference. We will work with organizers on coming up with a deadline for deciding whether or not we'll be going virtual, likely sometime around July. If you're considering hosting XDC, we've assembled a wiki page with what's generally expected and needed: https://www.x.org/wiki/Events/RFP/ When submitting your proposal, please make sure to include at least the key information about the potential location in question, possible dates along with estimated costs. Proposals can be submitted to board at foundation.x.org until the deadline of November 1st. Additionally, an quirk early heads-up to the board if you're considering hosting would be appreciated, in case we need to adjust the schedule a bit. Also, earlier is better since there generally will be a bit of Q with organizers. And if you just have some questions about what organizing XDC entails, please feel free to chat with previous organizers, or someone from the board. -- Sincerely, Lyude Paul (she/her) Software Engineer at Red Hat ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Individuals interested in VESA memberships?
Hi! So we can't give access to VESA stuff to non Xorg members, but membership is free! Also, since we're part of freedesktop.org now if your project is part of that we could probably get you an Xorg membership and go from there. Does that sound like something you'd be interested in? fwiw: https://members.x.org/ ← signup is here On Mon, 2019-11-04 at 23:54 -0500, Sanford Rockowitz wrote: > I'm interested in the VESA memberships. > > First off, let me acknowledge that I'm not active in X.org. If that is > disqualifying, so be it. However, I am the developer of ddcutil > (http://www.ddcutil.com), a utility for DDC/CI monitor control, that is > being adopted by Linux distributions, most notably the Debian/Ubuntu > family. > > There is enormous variability in how monitors implement the > specifications (see my rogues gallery at > http://www.ddcutil.com/monitor_notes), and there are many features of > the Monitor Control Command Set that I suspect have never been > implemented and never will be. For example, I've yet to see a monitor > that implements the Monitor Control Command Set (MCCS) version 3, and > suspect there never will be one. My interest is VESA membership is > twofold. First is to have access to the internal mailing lists, where I > can pose questions as to what is "really" going on. And second, there > are some older specs, e.g. MCCS version 2.1, that would be helpful to me > in properly interpreting data from monitors that are (ostensibly) built > to that spec. > > Regards, > Sanford Rockowitz > -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Individuals interested in VESA memberships?
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! -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Anyone interested in CoC training courtesy of X.Org?
Hi! This year we decided to start putting members of the CoC teams for Xorg and XDC through code of conduct training, paid for by the X.Org foundation and run by Otter Tech: https://otter.technology/code-of-conduct-training/ The training goes over practicing taking incident reports, following up with reporters, discussion on issues such as microaggressions and personal conflictsl, and frameworks for evaluating responses to reports. Having gone through the training myself, I can definitely I learned quite a bit from it and would highly recommend this to others who are planning on moderating communities. So since we have the resources to put more Xorg members through training we are considering the idea of sponsoring other Xorg members to go through this training as well, since this seemed to garner a decent amount of interest during XDC. So, I'm going around and poking a few different projects to figure out who all would be interested in such training. If there's any takers, or anyone has any questions, feel free to respond and let us know! -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] meson: Fix building with -Ddga=false
We forget to assign a value to xf86dgaproto_dep if -Ddga=false, which
causes the meson build to fail:
meson.build:448:0: ERROR: Unknown variable "xf86dgaproto_dep".
A full log can be found at /home/lyudess/build/xserver/meson-logs/meson-log.txt
FAILED: build.ninja
So, just set it to an empty dependency to fix that.
Signed-off-by: Lyude Paul
---
meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/meson.build b/meson.build
index 53cdbe2be..29794f083 100644
--- a/meson.build
+++ b/meson.build
@@ -407,6 +407,7 @@ if not build_xv
endif
build_dga = false
+xf86dgaproto_dep = dependency('', required: false)
if get_option('dga') == 'auto'
xf86dgaproto_dep = dependency('xf86dgaproto', version: '>= 2.0.99.1',
required: false)
if xf86dgaproto_dep.found()
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCHv3] modesetting: Update fb_id from shadow allocate and destroy if not set
Reviewed-by: Lyude Paul
On Thu, 2018-07-05 at 02:27 -0700, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
>
> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
>
> Let's fix this issue by going through all the displays.
>
> Cc: Hans De Goede
> Cc: Jason Ekstrand
> Cc: Keith Packard
> Cc: Laurent Pinchart
> Cc: Lyude Paul
> Cc: Sebastian Reichel
> Cc: Tomi Valkeinen
> Signed-off-by: Tony Lindgren
> ---
>
> Here's this one resent with proper patch description, sorry
> for the delays sending it out.
>
> ---
>
> hw/xfree86/drivers/modesetting/driver.c | 41 +++--
> 1 file changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/driver.c
> b/hw/xfree86/drivers/modesetting/driver.c
> --- a/hw/xfree86/drivers/modesetting/driver.c
> +++ b/hw/xfree86/drivers/modesetting/driver.c
> @@ -531,12 +531,11 @@ dispatch_dirty_region(ScrnInfoPtr scrn,
> }
>
> static void
> -dispatch_dirty(ScreenPtr pScreen)
> +dispatch_dirty_fb_id(ScreenPtr pScreen, int fb_id)
> {
> ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
> modesettingPtr ms = modesettingPTR(scrn);
> PixmapPtr pixmap = pScreen->GetScreenPixmap(pScreen);
> -int fb_id = ms->drmmode.fb_id;
> int ret;
>
> ret = dispatch_dirty_region(scrn, pixmap, ms->damage, fb_id);
> @@ -547,7 +546,43 @@ dispatch_dirty(ScreenPtr pScreen)
> ms->damage = NULL;
> xf86DrvMsg(scrn->scrnIndex, X_INFO,
> "Disabling kernel dirty updates, not required.\n");
> -return;
> +}
> +}
> +
> +static void
> +dispatch_dirty(ScreenPtr pScreen)
> +{
> +ScrnInfoPtr scrn = xf86ScreenToScrn(pScreen);
> +modesettingPtr ms = modesettingPTR(scrn);
> +modesettingEntPtr ms_ent = ms_ent_priv(scrn);
> +xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
> +xf86CrtcPtr crtc;
> +drmmode_crtc_private_ptr drmmode_crtc;
> +unsigned int mask;
> +
> +mask = ms_ent->assigned_crtcs;
> +
> +while (mask) {
> +int i, fb_id = 0;
> +
> +i = ffs(mask) - 1;
> +
> +crtc = xf86_config->crtc[i];
> +if (!ms_crtc_on(crtc))
> +goto skip;
> +
> +drmmode_crtc = crtc->driver_private;
> +
> +if (drmmode_crtc->rotate_fb_id)
> +fb_id = drmmode_crtc->rotate_fb_id;
> +else
> +fb_id = ms->drmmode.fb_id;
> +
> +if (fb_id)
> +dispatch_dirty_fb_id(pScreen, fb_id);
> +
> +skip:
> +mask &= ~(1 << i);
> }
> }
>
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] modesetting: Allow a DRM fd to be passed on command line with -masterfd
On Thu, 2018-06-28 at 12:39 -0700, Keith Packard wrote:
> Lyude Paul writes:
>
> > Looks good! One nitpick I'm not 100% sure about:
> > > +#define CHECK_FOR_REQUIRED_ARGUMENT() \
> > > +if (((i + 1) >= argc) || (!argv[i + 1])) {
> > > \
> > > + ErrorF("Required argument to %s not specified\n", argv[i]);
> > > \
> > > + UseMsg();
> > > \
> > > + FatalError("Required argument to %s not specified\n", argv[i]);
> >
> > Is the double printing of "Required argument to %s not specified" here
> > intentional?
>
> I copied CHECK_FOR_REQUIRED_ARGUMENT from xf86Init.c where it does the
> same thing. I assume this is intended to make sure the user understands
> what error caused the server to exit -- you can see it both before and
> after the long usage message.
Makes sense!
Reviewed-by: Lyude Paul
>
> > > +if (!xf86PrivsElevated())
> > > +ErrorF("-masterfd use the specified fd as the DRM
> > > master fd\n");
> >
> > I think it would be a better idea for us to show this argument description
> > unconditionally, along with adding a note about setuid/setgid not being
> > allowed with it
>
> Sounds good.
>
> Here's an updated patch with the usage message change suggested. Thanks
> for reviewing!
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] modesetting: Fix uninitialized memory usage in drmmode_crtc_get_fb_id()
This got reviewed off-list by Karol Herbst . It's a no-
brainer, so I'll push it in just a moment
On Wed, 2018-06-27 at 20:30 -0400, Lyude Paul wrote:
> This really sucked to find out :(
>
> Signed-off-by: Lyude Paul
> ---
> hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 375be4234..e27139d0e 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -604,6 +604,8 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t
> *fb_id, int *x, int *y)
> drmmode_ptr drmmode = drmmode_crtc->drmmode;
> int ret;
>
> +*fb_id = 0;
> +
> if (drmmode_crtc->prime_pixmap) {
> if (!drmmode->reverse_prime_offload_mode) {
> msPixmapPrivPtr ppriv =
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] modesetting: Fix uninitialized memory usage in drmmode_crtc_get_fb_id()
This really sucked to find out :(
Signed-off-by: Lyude Paul
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 375be4234..e27139d0e 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -604,6 +604,8 @@ drmmode_crtc_get_fb_id(xf86CrtcPtr crtc, uint32_t *fb_id,
int *x, int *y)
drmmode_ptr drmmode = drmmode_crtc->drmmode;
int ret;
+*fb_id = 0;
+
if (drmmode_crtc->prime_pixmap) {
if (!drmmode->reverse_prime_offload_mode) {
msPixmapPrivPtr ppriv =
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] modesetting: Allow a DRM fd to be passed on command line with -masterfd
t;
> diff --git a/hw/xfree86/os-support/linux/lnx_init.c b/hw/xfree86/os-
> support/linux/lnx_init.c
> index 9e5ddcd50..b654f7618 100644
> --- a/hw/xfree86/os-support/linux/lnx_init.c
> +++ b/hw/xfree86/os-support/linux/lnx_init.c
> @@ -356,6 +356,13 @@ xf86CloseConsole(void)
> close(xf86Info.consoleFd); /* make the vt-manager happy */
> }
>
> +#define CHECK_FOR_REQUIRED_ARGUMENT() \
> +if (((i + 1) >= argc) || (!argv[i + 1])) {
> \
> + ErrorF("Required argument to %s not specified\n", argv[i]);\
> + UseMsg(); \
> + FatalError("Required argument to %s not specified\n", argv[i]);
Is the double printing of "Required argument to %s not specified" here
intentional?
> \
> +}
> +
> int
> xf86ProcessArgument(int argc, char *argv[], int i)
> {
> @@ -376,6 +383,19 @@ xf86ProcessArgument(int argc, char *argv[], int i)
> }
> return 1;
> }
> +
> +if (!strcmp(argv[i], "-masterfd")) {
> +CHECK_FOR_REQUIRED_ARGUMENT();
> +if (xf86PrivsElevated())
> +FatalError("\nCannot specify -masterfd when server is
> setuid/setgid\n");
> +if (sscanf(argv[++i], "%d", ) != 1) {
> +UseMsg();
> +xf86DRMMasterFd = -1;
> +return 0;
> +}
> +return 2;
> +}
> +
> return 0;
> }
>
> @@ -385,4 +405,6 @@ xf86UseMsg(void)
> ErrorF("vtXX use the specified VT number\n");
> ErrorF("-keeptty ");
> ErrorF("don't detach controlling tty (for debugging only)\n");
> +if (!xf86PrivsElevated())
> +ErrorF("-masterfd use the specified fd as the DRM
> master fd\n");
I think it would be a better idea for us to show this argument description
unconditionally, along with adding a note about setuid/setgid not being
allowed with it
> }
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Linux-graphics-maintainer] [PATCH] glamor: Work around GEM usage v2
Pushed, thanks!
➜ xserver git:(master) git push
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 791 bytes | 791.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Updating patchwork state for
https://patchwork.freedesktop.org/project/Xorg/list/
remote: I: patch #230621 updated using rev
9f02855e7a1b7a3c1e2ee7bfbc73e87c29126920.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
dc90b1c3c..9f02855e7 master -> master
On Wed, 2018-06-20 at 20:18 +0200, Thomas Hellstrom wrote:
> On 06/20/2018 07:58 PM, Deepak Singh Rawat wrote:
> > The patch looks good to me just one question, I see that flink name
> > is returned as fd, so handle is what vmwgfx expecting in that case ?
>
> Yes. vmwgfx doesn't differentiate between handles and names.
>
> /Thomas
>
>
>
> >
> > Reviewed-by: Deepak Rawat
> >
> > > KMS drivers are not required to support GEM. In particular, vmwgfx
> > > doesn't support flink and handles and names are identical.
> > > Getting a bo name should really be part of a lower level API, if needed,
> > > but in the mean time work around this by setting the name identical to
> > > the handle if GEM isn't supported.
> > >
> > > This fixes modesetting driver dri2 on vmwgfx.
> > >
> > > Signed-off-by: Thomas Hellstrom
> > > ---
> > > v2: Strip changes to an unrelated file.
> > > ---
> > > glamor/glamor_egl.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
> > > index 4a4ca4bd8..7ec749742 100644
> > > --- a/glamor/glamor_egl.c
> > > +++ b/glamor/glamor_egl.c
> > > @@ -99,8 +99,18 @@ glamor_get_flink_name(int fd, int handle, int *name)
> > > struct drm_gem_flink flink;
> > >
> > > flink.handle = handle;
> > > -if (ioctl(fd, DRM_IOCTL_GEM_FLINK, ) < 0)
> > > -return FALSE;
> > > +if (ioctl(fd, DRM_IOCTL_GEM_FLINK, ) < 0) {
> > > +
> > > + /*
> > > + * Assume non-GEM kernels have names identical to the handle
> > > + */
> > > + if (errno == ENODEV) {
> > > + *name = handle;
> > > + return TRUE;
> > > + } else {
> > > + return FALSE;
> > > + }
> > > +}
> > > *name = flink.name;
> > > return TRUE;
> > > }
> > > --
> > > 2.14.3
> > >
> > > ___
> > > Sent to linux-graphics-maintai...@vmware.com
>
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set
yes if you wouldn't mind, after that I'll add it to the modesetting pull
On Fri, 2018-06-22 at 00:28 -0700, Tony Lindgren wrote:
> * Lyude Paul [180621 22:55]:
> > Hey, was a patch updated re: Keith's comments ever posted for this? Was
> > going
> > to review this, but I can't find any versions of this patch other than
> > this
> > one
>
> You got the second version already, that's patchworks:
>
> https://patchwork.freedesktop.org/patch/203834/
>
> Looks like it's missing the description, do you want
> me to resend it with the description below?
>
> Regards,
>
> Tony
>
> > On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote:
> > > Looks like drmModeDirtyFB() stopped working at some point and we now
> > > call it with fb_id of zero for rotated displays. This will stop displays
> > > relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
> > >
> > > This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> > > support for using RandR shadow buffers") that inroduced rotate_fb_id.
> > >
> > > Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> > > reset it back to zero after we're done with the rotation.
> > >
> > > After the fix we then call drmModeDirtyFB() we then have the
> > > following fb_id changes:
> > >
> > > $ startx
> > > drmmode_get_default_bpp: fb_id: 51
> > > drmmode_get_default_bpp: cleared fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_set_mode_major: drmmode->fb_id: 52
> > > dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
> > > ...
> > >
> > > $ xrandr --output DSI-1 --rotate right
> > > drmmode_xf86crtc_resize: cleared old_fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
> > > dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
> > > ...
> > >
> > > $ xrandr --output DSI-1 --rotate normal
> > > drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> > > drmmode_set_mode_major: drmmode->fb_id: 51
> > > dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
> > > ...
> > >
> > > Cc: Hans De Goede
> > > Cc: Jason Ekstrand
> > > Cc: Laurent Pinchart
> > > Cc: Sebastian Reichel
> > > Cc: Tomi Valkeinen
> > > Signed-off-by: Tony Lindgren
> > > ---
> > > hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
> > > hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> > > @@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int
> > > width,
> > > int height)
> > > return NULL;
> > > }
> > >
> > > +/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
> > > +if (!drmmode->fb_id) {
> > > +drmmode->fb_id = drmmode_crtc->rotate_fb_id;
> > > +drmmode_crtc->reset_fb_id = TRUE;
> > > +}
> > > +
> > > #ifdef GLAMOR_HAS_GBM
> > > if (drmmode->gbm)
> > > return drmmode_crtc->rotate_bo.gbm;
> > > @@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc,
> > > PixmapPtr
> > > rotate_pixmap, void *data)
> > >
> > > if (data) {
> > > drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
> > > + if (drmmode_crtc->reset_fb_id &&
> > > +drmmode->fb_id == drmmode_crtc->rotate_fb_id)
> > > +drmmode->fb_id = 0;
> > > +drmmode_crtc->reset_fb_id = FALSE;
> > > drmmode_crtc->rotate_fb_id = 0;
> > >
> > > drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > --- a/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
> > > @@ -98,6 +98,7 @@ typedef struct {
> > >
> > > drmmode_bo rotate_bo;
> > > unsigned rotate_fb_id;
> > > +Bool reset_fb_id;
> > >
> > > PixmapPtr prime_pixmap;
> > > PixmapPtr prime_pixmap_back;
> >
> > --
> > Cheers,
> > Lyude Paul
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] meson: ensure the libc has RPC functions when secure-rpc is enabled
Currently our meson.build just makes the assumption that the libc is
going to provide RPC functions. This doesn't actually seem to be the
case on Fedora, which causes compilation to fail unexpectedly:
../../Projects/xserver/os/rpcauth.c:47:10: fatal error: rpc/rpc.h: No such file
or directory
#include
^~~
compilation terminated.
So, in the event that we can't use libtirpc ensure that we actually
check whether or not the libc provides rpc/rpc.h. If it doesn't, raise
an error.
Signed-off-by: Lyude Paul
---
os/meson.build | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/os/meson.build b/os/meson.build
index eb8fcf55d..0e41f9c02 100644
--- a/os/meson.build
+++ b/os/meson.build
@@ -56,9 +56,13 @@ endif
rpc_dep = []
if get_option('secure-rpc')
-# prefer libtirpc (if available), otherwise assume RPC functions are
+# prefer libtirpc (if available), otherwise ensure RPC functions are
# provided by libc.
rpc_dep = dependency('libtirpc', required: false)
+if not (rpc_dep.found() or cc.has_header('rpc/rpc.h'))
+error('secure-rpc requested, but neither libtirpc or libc RPC support
were found')
+endif
+
srcs_os += 'rpcauth.c'
endif
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] modesetting: Update fb_id from shadow allocate and destroy if not set
Hey, was a patch updated re: Keith's comments ever posted for this? Was going
to review this, but I can't find any versions of this patch other than this
one
On Sat, 2018-02-03 at 10:34 -0800, Tony Lindgren wrote:
> Looks like drmModeDirtyFB() stopped working at some point and we now
> call it with fb_id of zero for rotated displays. This will stop displays
> relying on DRM_IOCTL_MODE_DIRTYFB ioctl to display anything.
>
> This regression probably with commit 3dcd591fa9b7 ("modesetting: Add
> support for using RandR shadow buffers") that inroduced rotate_fb_id.
>
> Let's fix this issue by copying rotate_fb_id to fb_id if zero and then
> reset it back to zero after we're done with the rotation.
>
> After the fix we then call drmModeDirtyFB() we then have the
> following fb_id changes:
>
> $ startx
> drmmode_get_default_bpp: fb_id: 51
> drmmode_get_default_bpp: cleared fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_set_mode_major: drmmode->fb_id: 52
> dispatch_dirty: ms->drmmode.fb_id: 52 fb_id: 52
> ...
>
> $ xrandr --output DSI-1 --rotate right
> drmmode_xf86crtc_resize: cleared old_fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_shadow_allocate: drmmode_crtc->rotate_fb_id: 50
> dispatch_dirty: ms->drmmode.fb_id: 50 fb_id: 50
> ...
>
> $ xrandr --output DSI-1 --rotate normal
> drmmode_shadow_destroy: cleared drmmode_crtc->rotate_fb_id
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> dispatch_dirty: ms->drmmode.fb_id: 0 fb_id: 0
> drmmode_set_mode_major: drmmode->fb_id: 51
> dispatch_dirty: ms->drmmode.fb_id: 51 fb_id: 51
> ...
>
> Cc: Hans De Goede
> Cc: Jason Ekstrand
> Cc: Laurent Pinchart
> Cc: Sebastian Reichel
> Cc: Tomi Valkeinen
> Signed-off-by: Tony Lindgren
> ---
> hw/xfree86/drivers/modesetting/drmmode_display.c | 10 ++
> hw/xfree86/drivers/modesetting/drmmode_display.h | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -997,6 +997,12 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int width,
> int height)
> return NULL;
> }
>
> +/* Must have proper drmmode->fb_id for drmModeDirtyFB() */
> +if (!drmmode->fb_id) {
> +drmmode->fb_id = drmmode_crtc->rotate_fb_id;
> +drmmode_crtc->reset_fb_id = TRUE;
> +}
> +
> #ifdef GLAMOR_HAS_GBM
> if (drmmode->gbm)
> return drmmode_crtc->rotate_bo.gbm;
> @@ -1084,6 +1090,10 @@ drmmode_shadow_destroy(xf86CrtcPtr crtc, PixmapPtr
> rotate_pixmap, void *data)
>
> if (data) {
> drmModeRmFB(drmmode->fd, drmmode_crtc->rotate_fb_id);
> +if (drmmode_crtc->reset_fb_id &&
> +drmmode->fb_id == drmmode_crtc->rotate_fb_id)
> +drmmode->fb_id = 0;
> +drmmode_crtc->reset_fb_id = FALSE;
> drmmode_crtc->rotate_fb_id = 0;
>
> drmmode_bo_destroy(drmmode, _crtc->rotate_bo);
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.h
> b/hw/xfree86/drivers/modesetting/drmmode_display.h
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.h
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.h
> @@ -98,6 +98,7 @@ typedef struct {
>
> drmmode_bo rotate_bo;
> unsigned rotate_fb_id;
> +Bool reset_fb_id;
>
> PixmapPtr prime_pixmap;
> PixmapPtr prime_pixmap_back;
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver v2 1/2] glamor: Unbreak glamor_fd_from_pixmap()
On Thu, 2018-06-21 at 08:38 +0100, Daniel Stone wrote:
> Hey Lyude,
> On Thu, 21 Jun 2018 at 00:13, Lyude Paul wrote:
> > -/* Pixmaps with multi-planes/modifier are not supported in this
> > interface */
> > -if (ret != 1 || offsets[0] != 0) {
> > -while (ret > 0)
> > -close(fds[--ret]);
> > +ret = _glamor_fds_from_pixmap(screen, pixmap, , , NULL,
> > size,
> > + NULL);
> > +if (ret != 1)
> > return -1;
>
> This needs the removed code just above it, where it closes excess FDs.
> I think the rest looks good though; I don't have a PRIME system so
> wasn't able to test at the time.
I think there is a misunderstanding here, as that bit of code was the bug this
patch is supposed to fix. There's nothing excess it's closing, it either gets
a single plane non-modifier bo (which never actually happens) and returns
that, or gets a multi plane bo with modifiers and drops the bo entirely by
closing all of it's file descriptors and returning -1.
We avoid that problem entirely in the new code by making it so that
glamor_fd_from_pixmap() doesn't pass modifiers to _glamor_fds_from_pixmap(),
which makes _glamor_fds_from_pixmap() call glamor_egl_fd_from_pixmap() which
is only capable of returning a single file descriptor for a bo without
modifiers or multiple planes.
>
> Cheers,
> Daniel
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [Linux-graphics-maintainer] [PATCH] glamor: Work around GEM usage v2
Added to the modesetting pull request:
https://gitlab.freedesktop.org/lyudess/xserver/commit/49a2dae2dc45b4a144ae69be47a90ce6f4ca27f8
Thanks!
On Wed, 2018-06-20 at 20:18 +0200, Thomas Hellstrom wrote:
> On 06/20/2018 07:58 PM, Deepak Singh Rawat wrote:
> > The patch looks good to me just one question, I see that flink name
> > is returned as fd, so handle is what vmwgfx expecting in that case ?
>
> Yes. vmwgfx doesn't differentiate between handles and names.
>
> /Thomas
>
>
>
> >
> > Reviewed-by: Deepak Rawat
> >
> > > KMS drivers are not required to support GEM. In particular, vmwgfx
> > > doesn't support flink and handles and names are identical.
> > > Getting a bo name should really be part of a lower level API, if needed,
> > > but in the mean time work around this by setting the name identical to
> > > the handle if GEM isn't supported.
> > >
> > > This fixes modesetting driver dri2 on vmwgfx.
> > >
> > > Signed-off-by: Thomas Hellstrom
> > > ---
> > > v2: Strip changes to an unrelated file.
> > > ---
> > > glamor/glamor_egl.c | 14 --
> > > 1 file changed, 12 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
> > > index 4a4ca4bd8..7ec749742 100644
> > > --- a/glamor/glamor_egl.c
> > > +++ b/glamor/glamor_egl.c
> > > @@ -99,8 +99,18 @@ glamor_get_flink_name(int fd, int handle, int *name)
> > > struct drm_gem_flink flink;
> > >
> > > flink.handle = handle;
> > > -if (ioctl(fd, DRM_IOCTL_GEM_FLINK, ) < 0)
> > > -return FALSE;
> > > +if (ioctl(fd, DRM_IOCTL_GEM_FLINK, ) < 0) {
> > > +
> > > + /*
> > > + * Assume non-GEM kernels have names identical to the handle
> > > + */
> > > + if (errno == ENODEV) {
> > > + *name = handle;
> > > + return TRUE;
> > > + } else {
> > > + return FALSE;
> > > + }
> > > +}
> > > *name = flink.name;
> > > return TRUE;
> > > }
> > > --
> > > 2.14.3
> > >
> > > ___
> > > Sent to linux-graphics-maintai...@vmware.com
>
>
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Gathering EGLStream related changed for Xwayland for a pull request
On Mon, 2018-06-18 at 14:50 -0400, Lyude Paul wrote: > Hey guys! So, talking to Ajax he said that something which would probably > help > out with getting a bugfix release out there for X is if people started > getting > their changes together into pull requests so that he doesn't need to go > through a bunch of threads and figure out what needs to be pulled in or not. > > I've got some other stuff I need to make sure gets fixed in the X server, > but > for now as far as I can tell all of the EGLStream related fixes we need to > get > in Xwayland are reviewed and ready for a pull request. This includes: > > https://cgit.freedesktop.org/~ofourdan/xserver/log/?h=xwayland > (thanks Olivier for putting everything in one place!) > > If anyone else has EGLStream related stuff they would like to get in that I > missed, it's probably a good idea to respond to this! Time's up! Merge request now live at https://gitlab.freedesktop.org/ajax/xserver/merge_requests/1 (yes, this is going to go back up into the cgit repo for now if any readers were wondering. we haven't switched to gitlab entirely yet, unfortunately...) > -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver v2 2/2] randr: Scream when creating a shared pixmap fails
This seems like a problem worth screaming about.
Signed-off-by: Lyude Paul
---
randr/rrcrtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index d7d937e80..74dc5a265 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -534,6 +534,7 @@ rrSetupPixmapSharing(RRCrtcPtr crtc, int width, int height,
width, height, depth,
x, y, rotation);
if (spix_front == NULL) {
+ErrorF("randr: failed to create shared pixmap\n");
return FALSE;
}
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver v2 1/2] glamor: Unbreak glamor_fd_from_pixmap()
When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.
This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:
- Find a laptop with DRI prime that has outputs connected to the
dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail
Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
---
Changes since v1:
- Don't use void* in _glamor_fds_from_pixmap(), instead retain the
copying of the value from CARD16 → uint32_t* and back that the
original code did (re: airlied)
glamor/glamor.c | 56 ++-
glamor/glamor.h | 3 +-
glamor/glamor_egl.c | 2 +-
glamor/glamor_egl_stubs.c | 7
hw/xwayland/xwayland-glamor-gbm.c | 10 ++
5 files changed, 53 insertions(+), 25 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 54ca0db35..9bf1707de 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -826,10 +826,10 @@ glamor_get_drawable_modifiers(DrawablePtr draw, uint32_t
format,
return TRUE;
}
-_X_EXPORT int
-glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
- uint32_t *strides, uint32_t *offsets,
- uint64_t *modifier)
+static int
+_glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
+uint32_t *strides, uint32_t *offsets,
+CARD32 *size, uint64_t *modifier)
{
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
glamor_screen_private *glamor_priv =
@@ -843,39 +843,49 @@ glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr
pixmap, int *fds,
if (!glamor_pixmap_ensure_fbo(pixmap, pixmap->drawable.depth == 30 ?
GL_RGB10_A2 : GL_RGBA, 0))
return 0;
-return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
- strides, offsets,
- modifier);
+
+if (modifier) {
+return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
+ strides, offsets,
+ modifier);
+} else {
+CARD16 stride;
+
+fds[0] = glamor_egl_fd_from_pixmap(screen, pixmap, , size);
+strides[0] = stride;
+
+return fds[0] >= 0;
+}
default:
break;
}
return 0;
}
+_X_EXPORT int
+glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
+ uint32_t *strides, uint32_t *offsets,
+ uint64_t *modifier)
+{
+return _glamor_fds_from_pixmap(screen, pixmap, fds, strides, offsets,
+ NULL, modifier);
+}
+
_X_EXPORT int
glamor_fd_from_pixmap(ScreenPtr screen,
PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
+int fd;
int ret;
-int fds[4];
-uint32_t strides[4], offsets[4];
-uint64_t modifier;
-
-ret = glamor_fds_from_pixmap(screen, pixmap, fds, strides, offsets,
- );
+uint32_t stride32;
-/* Pixmaps with multi-planes/modifier are not supported in this interface
*/
-if (ret != 1 || offsets[0] != 0) {
-while (ret > 0)
-close(fds[--ret]);
+ret = _glamor_fds_from_pixmap(screen, pixmap, , , NULL, size,
+ NULL);
+if (ret != 1)
return -1;
-}
-ret = fds[0];
-*stride = strides[0];
-*size = pixmap->drawable.height * *stride;
-
-return ret;
+*stride = stride32;
+return fd;
}
_X_EXPORT int
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 06e11506f..09e9c895c 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -141,7 +141,7 @@ extern _X_EXPORT void glamor_egl_exchange_buffers(PixmapPtr
front,
extern _X_EXPORT void glamor_pixmap_exchange_fbos(PixmapPtr front,
PixmapPtr back);
-/* The DDX is not supposed to call these three functions */
+/* The DDX is not suppo
[PATCH xserver 1/2] glamor: Unbreak glamor_fd_from_pixmap()
When support for allocating GBM BOs with modifiers was added,
glamor_fd_from_pixmap() was changed so that it would return an error if
it got a bo with modifiers set from glamor_fds_from_pixmap(). The
problem is that on systems that support BOs with modifiers,
glamor_fds_from_pixmap() will always return BOs with modifiers.
This means that glamor_fd_from_pixmap() was broken entirely, which broke
a number of other things including glamor_shareable_fd_from_pixmap(),
which meant that modesetting using multiple GPUs with the modesetting
DDX was also broken. Easy reproducer:
- Find a laptop with DRI prime that has outputs connected to the
dedicated GPU and integrated GPU
- Try to enable one display on each using the modesetting DDX
- Fail
Since there isn't a way to ask for no modifiers from
glamor_fds_from_pixmap, we create a shared _glamor_fds_from_pixmap()
function used by both glamor_fds_from_pixmap() and
glamor_fd_from_pixmap() that calls down to the appropriate
glamor_egl_fd*_from_pixmap() function.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap")
---
glamor/glamor.c | 52 +--
glamor/glamor.h | 3 +-
glamor/glamor_egl.c | 2 +-
glamor/glamor_egl_stubs.c | 7 +
hw/xwayland/xwayland-glamor-gbm.c | 10 ++
5 files changed, 48 insertions(+), 26 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index 54ca0db35..aaa528545 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -826,10 +826,10 @@ glamor_get_drawable_modifiers(DrawablePtr draw, uint32_t
format,
return TRUE;
}
-_X_EXPORT int
-glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
- uint32_t *strides, uint32_t *offsets,
- uint64_t *modifier)
+static int
+_glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
+void *strides, uint32_t *offsets,
+CARD32 *size, uint64_t *modifier)
{
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
glamor_screen_private *glamor_priv =
@@ -843,39 +843,43 @@ glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr
pixmap, int *fds,
if (!glamor_pixmap_ensure_fbo(pixmap, pixmap->drawable.depth == 30 ?
GL_RGB10_A2 : GL_RGBA, 0))
return 0;
-return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
- strides, offsets,
- modifier);
+
+if (modifier) {
+return glamor_egl_fds_from_pixmap(screen, pixmap, fds,
+ strides, offsets,
+ modifier);
+} else {
+fds[0] = glamor_egl_fd_from_pixmap(screen, pixmap, strides, size);
+return fds[0] >= 0;
+}
default:
break;
}
return 0;
}
+_X_EXPORT int
+glamor_fds_from_pixmap(ScreenPtr screen, PixmapPtr pixmap, int *fds,
+ uint32_t *strides, uint32_t *offsets,
+ uint64_t *modifier)
+{
+return _glamor_fds_from_pixmap(screen, pixmap, fds, strides, offsets,
+ NULL, modifier);
+}
+
_X_EXPORT int
glamor_fd_from_pixmap(ScreenPtr screen,
PixmapPtr pixmap, CARD16 *stride, CARD32 *size)
{
+int fd;
int ret;
-int fds[4];
-uint32_t strides[4], offsets[4];
-uint64_t modifier;
-
-ret = glamor_fds_from_pixmap(screen, pixmap, fds, strides, offsets,
- );
-/* Pixmaps with multi-planes/modifier are not supported in this interface
*/
-if (ret != 1 || offsets[0] != 0) {
-while (ret > 0)
-close(fds[--ret]);
+ret = _glamor_fds_from_pixmap(screen, pixmap, , stride, NULL, size,
+ NULL);
+if (ret == 1)
+return fd;
+else
return -1;
-}
-
-ret = fds[0];
-*stride = strides[0];
-*size = pixmap->drawable.height * *stride;
-
-return ret;
}
_X_EXPORT int
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 06e11506f..09e9c895c 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -141,7 +141,7 @@ extern _X_EXPORT void glamor_egl_exchange_buffers(PixmapPtr
front,
extern _X_EXPORT void glamor_pixmap_exchange_fbos(PixmapPtr front,
PixmapPtr back);
-/* The DDX is not supposed to call these three functions */
+/* The DDX is not supposed to call these four functions */
extern _X_EXPORT void glamor_enable_dri3(ScreenPtr screen);
extern _X_EXPORT int glamor_egl_fds_from_pixmap(ScreenPtr, PixmapPtr, int *,
uint32_t *, uint32_t *,
@@ -150,6 +150,7 @
[PATCH xserver 2/2] randr: Scream when creating a shared pixmap fails
This seems like a problem worth screaming about.
Signed-off-by: Lyude Paul
---
randr/rrcrtc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index d7d937e80..74dc5a265 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -534,6 +534,7 @@ rrSetupPixmapSharing(RRCrtcPtr crtc, int width, int height,
width, height, depth,
x, y, rotation);
if (spix_front == NULL) {
+ErrorF("randr: failed to create shared pixmap\n");
return FALSE;
}
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Grabbing modesetting ddx related patches for pull request
On Wed, 2018-06-20 at 16:46 +0200, Thomas Hellstrom wrote: > On 06/18/2018 10:48 PM, Lyude Paul wrote: > > To help ajax out with getting a bug release out for Xorg, we figured it > > would > > be a good idea for me to go through the stuff I needed to get upstream and > > file pull requests for all of it. This is pretty much the same thing as > > what > > I'm doing for EGLStreams stuff in Xwayland, except for modesetting. > > > > For starters, my current WIP branch for this pull lives at: > > > > ... > > > > > If I've missed anyone's patches, please feel free to respond to this > > email. > > I'll give an update when I think it's ready for pulling time (which should > > hopefully not be too long from now). > > > > Could we have "glamor: Work around GEM usage v2" included as well? > Currently xf86-video-modesetting is broken with vmwgfx. This is one of > the problems I've identified. > hm... actually the only version of this patch I can currently find is: https://patchwork.freedesktop.org/patch/224908/ Are you sure you got around to resending it? > /Thomas > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Grabbing modesetting ddx related patches for pull request
On Wed, 2018-06-20 at 16:46 +0200, Thomas Hellstrom wrote: > On 06/18/2018 10:48 PM, Lyude Paul wrote: > > To help ajax out with getting a bug release out for Xorg, we figured it > > would > > be a good idea for me to go through the stuff I needed to get upstream and > > file pull requests for all of it. This is pretty much the same thing as > > what > > I'm doing for EGLStreams stuff in Xwayland, except for modesetting. > > > > For starters, my current WIP branch for this pull lives at: > > > > ... > > > > > If I've missed anyone's patches, please feel free to respond to this > > email. > > I'll give an update when I think it's ready for pulling time (which should > > hopefully not be too long from now). > > > > Could we have "glamor: Work around GEM usage v2" included as well? > Currently xf86-video-modesetting is broken with vmwgfx. This is one of > the problems I've identified. Sounds fine to me, I will add it to my list of patches to get reviewed/pulled in (unless it's already reviewed?) > > /Thomas > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Grabbing modesetting ddx related patches for pull request
To help ajax out with getting a bug release out for Xorg, we figured it would be a good idea for me to go through the stuff I needed to get upstream and file pull requests for all of it. This is pretty much the same thing as what I'm doing for EGLStreams stuff in Xwayland, except for modesetting. For starters, my current WIP branch for this pull lives at: https://gitlab.freedesktop.org/lyudess/xserver/tree/wip/modesetting-pull This contains all the modesetting patches on patchwork I could find that have been reviewed and are ready to go. Additionally, there's a rather important fix for the modesetting ddx regarding the new partial atomic support that I haven't written up yet that will be included in this too. Other then that, there's currently some patches on the ML that I found which need reviews: * "modesetting: Update fb_id from shadow allocate and destroy if not set" from Tony Lindgren: https://patchwork.freedesktop.org/patch/203834/ * "modesetting: Allow a DRM fd to be passed on command line with -masterfd" from Keith Packard https://patchwork.freedesktop.org/patch/207655/ I will try to give a review of these, but reviews from others would be appreciated as well since there are probably people a lot more experienced with this ddx than I on this list :). If I've missed anyone's patches, please feel free to respond to this email. I'll give an update when I think it's ready for pulling time (which should hopefully not be too long from now). -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] modesetting: use drmmode_bo_import() for rotate_fb
Reviewed-by: Lyude Paul
On Fri, 2018-06-15 at 08:57 +0200, Olivier Fourdan wrote:
> drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if
> the format is not as expected, preventing from using a rotated output.
>
> Change it to use the new function drmmode_bo_import() which takes care
> of calling the drmModeAddFB2() API.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106715
> Signed-off-by: Olivier Fourdan
> ---
> hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 859a21a9d..ec11b3f56 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -1794,11 +1794,8 @@ drmmode_shadow_allocate(xf86CrtcPtr crtc, int width,
> int height)
> return NULL;
> }
>
> -ret = drmModeAddFB(drmmode->fd, width, height, crtc->scrn->depth,
> - drmmode->kbpp,
> - drmmode_bo_get_pitch(_crtc->rotate_bo),
> - drmmode_bo_get_handle(_crtc->rotate_bo),
> - _crtc->rotate_fb_id);
> +ret = drmmode_bo_import(drmmode, _crtc->rotate_bo,
> +_crtc->rotate_fb_id);
>
> if (ret) {
> ErrorF("failed to add rotate fb\n");
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Gathering EGLStream related changed for Xwayland for a pull request
Hey guys! So, talking to Ajax he said that something which would probably help out with getting a bugfix release out there for X is if people started getting their changes together into pull requests so that he doesn't need to go through a bunch of threads and figure out what needs to be pulled in or not. I've got some other stuff I need to make sure gets fixed in the X server, but for now as far as I can tell all of the EGLStream related fixes we need to get in Xwayland are reviewed and ready for a pull request. This includes: https://cgit.freedesktop.org/~ofourdan/xserver/log/?h=xwayland (thanks Olivier for putting everything in one place!) If anyone else has EGLStream related stuff they would like to get in that I missed, it's probably a good idea to respond to this! -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: gitlab migration
On Tue, 2018-06-12 at 17:38 -0400, James Cloos wrote: > Two comments: > > BZ is superior to GL (or GH or the like). > > Mailing lists are vastly superior to any web-only crap. 'web-only' is only a problem until you actually go write a command line client for it. Which, you can do if you really need these sort of workflows. Additionally I'm with daniels here, Gitlab and Github are two massively different things with different workflows and if you're just going off the assumption "if it sounds like the word Github then it must be another github" you're not actually contributing anything useful to the discussion, especially if you don't actually provide any points as to "gitlab is bad because of X or Y reason". > > -JimC -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/2] xwayland: mandatory EGL backend API
Reviewed-by: Lyude Paul
On Mon, 2018-06-11 at 10:22 +0200, Olivier Fourdan wrote:
> The API init_wl_registry() and has_wl_interfaces() are marked as being
> optional, but both GBM And EGLStream backends implement them so there is
> point in keeping those optional.
>
> Suggested-by: Emil Velikov
> Signed-off-by: Olivier Fourdan
> ---
> hw/xwayland/xwayland-glamor.c | 8 +---
> hw/xwayland/xwayland.h| 6 ++
> 2 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index 61418e707..f17914344 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -72,14 +72,12 @@ xwl_glamor_init_wl_registry(struct xwl_screen *xwl_screen,
> uint32_t version)
> {
> if (xwl_screen->gbm_backend.is_available &&
> -xwl_screen->gbm_backend.init_wl_registry &&
> xwl_screen->gbm_backend.init_wl_registry(xwl_screen,
> registry,
> id,
> interface,
> version)); /* no-op */
> else if (xwl_screen->eglstream_backend.is_available &&
> - xwl_screen->eglstream_backend.init_wl_registry &&
> xwl_screen->eglstream_backend.init_wl_registry(xwl_screen,
> registry,
> id,
> @@ -91,11 +89,7 @@ Bool
> xwl_glamor_has_wl_interfaces(struct xwl_screen *xwl_screen,
> struct xwl_egl_backend *xwl_egl_backend)
> {
> -if (xwl_egl_backend->has_wl_interfaces)
> -return xwl_egl_backend->has_wl_interfaces(xwl_screen);
> -
> -/* If the backend has no requirement wrt WL interfaces, we're fine */
> -return TRUE;
> +return xwl_egl_backend->has_wl_interfaces(xwl_screen);
> }
>
> struct wl_buffer *
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index dc01c747c..d70ad54bf 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -64,16 +64,14 @@ struct xwl_egl_backend {
> Bool is_available;
>
> /* Called once for each interface in the global registry. Backends
> - * should use this to bind to any wayland interfaces they need. This
> - * callback is optional.
> + * should use this to bind to any wayland interfaces they need.
> */
> Bool (*init_wl_registry)(struct xwl_screen *xwl_screen,
> struct wl_registry *wl_registry,
> uint32_t id, const char *name,
> uint32_t version);
>
> -/* Check that the required Wayland interfaces are available. This
> - * callback is optional.
> +/* Check that the required Wayland interfaces are available.
> */
> Bool (*has_wl_interfaces)(struct xwl_screen *xwl_screen);
>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] modesetting: Also disable CRTC in drmmode_output_disable()
So, this did actually work on older kernels at one point in time,
however it seems that this working was a result of some of the Linux
kernel's atomic modesetting helpers not preserving the CRTC's enabled
state in the right spots. This was fixed in:
846c7dfc1193 ("drm/atomic: Try to preserve the crtc enabled state in
drm_atomic_remove_fb, v2")
As a result, atomic commits which simply disassociate a DRM connector
with it's CRTC while leaving the CRTC in an enabled state aren't enough
to disable the CRTC, and result in the atomic commit failing. This
currently can cause issues with MST hotplugging where X will end up
failing to disable the MST outputs after they've left the system. A
simple reproducer:
- Start up Xorg
- Connect an MST hub with displays connected to it
- Remove the hub
- Now there should be CRTCs stuck on the orphaned MST connectors, and X
won't be able to reclaim them.
Signed-off-by: Lyude Paul
Cc: Louis-Francis Ratté-Boulianne
---
hw/xfree86/drivers/modesetting/drmmode_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index 859a21a9d..375be4234 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -695,18 +695,21 @@ drmmode_output_disable(xf86OutputPtr output)
{
modesettingPtr ms = modesettingPTR(output->scrn);
drmmode_output_private_ptr drmmode_output = output->driver_private;
+xf86CrtcPtr crtc = drmmode_output->current_crtc;
drmModeAtomicReq *req = drmModeAtomicAlloc();
uint32_t flags = DRM_MODE_ATOMIC_ALLOW_MODESET;
-int ret;
+int ret = 0;
assert(ms->atomic_modeset);
if (!req)
return 1;
-/* XXX Can we disable all outputs without disabling CRTC right away? */
-ret = connector_add_prop(req, drmmode_output,
- DRMMODE_CONNECTOR_CRTC_ID, 0);
+ret |= connector_add_prop(req, drmmode_output,
+ DRMMODE_CONNECTOR_CRTC_ID, 0);
+if (crtc)
+ret |= crtc_add_dpms_props(req, crtc, DPMSModeOff, NULL);
+
if (ret == 0)
ret = drmModeAtomicCommit(ms->fd, req, flags, NULL);
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 00/10] Re: Refactor egl_backends for wayland registry
Sweet! Everything looks good to me For the whole series: Reviewed-by: Lyude Paul On Tue, 2018-06-05 at 19:38 +0200, Olivier Fourdan wrote: > Hi, > > This is a follow-up on https://patchwork.freedesktop.org/series/44095/ > after Lyude and Emil reviews. > > Cheers, > Olivier > > Olivier Fourdan (10): > xwayland: move glamor specific routines > xwayland: swap "name" and "id" in init_wl_registry() > xwayland: GBM should fail w/out "GL_OES_EGL_image" > xwayland: skip drm authentication with render node > xwayland: move egl_backend to its own struct > xwayland: Add Wayland interfaces check > xwayland: move EGL backend init to glamor > xwayland: refactor EGL backends for wayland registry > xwayland: check for EGLStream backend explicitly > xwayland: EGL_IMG_context_priority required by EGLStream > > hw/xwayland/xwayland-glamor-eglstream.c | 152 +++ > hw/xwayland/xwayland-glamor-gbm.c | 69 +++-- > hw/xwayland/xwayland-glamor.c | 186 > hw/xwayland/xwayland-present.c | 5 +- > hw/xwayland/xwayland.c | 28 ++-- > hw/xwayland/xwayland.h | 151 ++- > 6 files changed, 369 insertions(+), 222 deletions(-) > -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 5/5] xwayland: refactor egl_backends for wayland registry
it_wl_registry &&
> + xwl_screen->eglstreams_backend.init_wl_registry(xwl_screen,
> + registry,
> + id,
> + interface,
> + version)); /*
> no-op */
> +#endif
> }
>
> Bool
> @@ -95,8 +110,8 @@ xwl_glamor_pixmap_get_wl_buffer(PixmapPtr pixmap,
> {
> struct xwl_screen *xwl_screen = xwl_screen_get(pixmap-
> >drawable.pScreen);
>
> -if (xwl_screen->egl_backend.get_wl_buffer_for_pixmap)
> -return xwl_screen->egl_backend.get_wl_buffer_for_pixmap(pixmap,
> +if (xwl_screen->egl_backend->get_wl_buffer_for_pixmap)
> +return xwl_screen->egl_backend->get_wl_buffer_for_pixmap(pixmap,
> width,
> height,
> created);
> @@ -110,8 +125,8 @@ xwl_glamor_post_damage(struct xwl_window *xwl_window,
> {
> struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
>
> -if (xwl_screen->egl_backend.post_damage)
> -xwl_screen->egl_backend.post_damage(xwl_window, pixmap, region);
> +if (xwl_screen->egl_backend->post_damage)
> +xwl_screen->egl_backend->post_damage(xwl_window, pixmap, region);
> }
>
> Bool
> @@ -119,8 +134,8 @@ xwl_glamor_allow_commits(struct xwl_window *xwl_window)
> {
> struct xwl_screen *xwl_screen = xwl_window->xwl_screen;
>
> -if (xwl_screen->egl_backend.allow_commits)
> -return xwl_screen->egl_backend.allow_commits(xwl_window);
> +if (xwl_screen->egl_backend && xwl_screen->egl_backend->allow_commits)
> +return xwl_screen->egl_backend->allow_commits(xwl_window);
> else
> return TRUE;
> }
> @@ -165,17 +180,35 @@ glamor_egl_fd_name_from_pixmap(ScreenPtr screen,
> void
> xwl_glamor_init_backends(struct xwl_screen *xwl_screen, Bool
> use_eglstreams)
> {
> +#ifdef GLAMOR_HAS_GBM
> +/* Init GBM even if "-eglstream" is requested, as EGL streams may fail
> */
> +xwl_glamor_init_gbm(xwl_screen);
> +#endif
> #ifdef XWL_HAS_EGLSTREAM
> +xwl_glamor_init_eglstream(xwl_screen);
> if (use_eglstreams) {
> -if (!xwl_glamor_init_eglstream(xwl_screen)) {
> -ErrorF("xwayland glamor: failed to setup eglstream backend\n");
> -use_eglstreams = FALSE;
> -}
> +/* Force GBM backend off */
> +xwl_screen->gbm_backend.is_available = FALSE;
> +if (!xwl_screen->eglstreams_backend.is_available)
> +ErrorF("xwayland glamor: EGLstreams requested but not
> available\n");
> }
> #endif
> -if (!use_eglstreams && !xwl_glamor_init_gbm(xwl_screen)) {
> -ErrorF("xwayland glamor: failed to setup GBM backend, falling back
> to sw accel\n");
> -xwl_screen->glamor = 0;
> +}
> +
> +void
> +xwl_glamor_select_backend(struct xwl_screen *xwl_screen, Bool
> use_eglstreams)
> +{
> +if (xwl_screen->egl_backend == NULL && xwl_screen-
> >gbm_backend.is_available) {
> +if (xwl_glamor_has_wl_interfaces(xwl_screen, _screen-
> >gbm_backend))
> +xwl_screen->egl_backend = _screen->gbm_backend;
> +else
> +ErrorF("Missing Wayland requirements for glamor GBM
> backend\n");
> +}
> +if (xwl_screen->egl_backend == NULL && xwl_screen-
> >eglstreams_backend.is_available) {
> +if (xwl_glamor_has_wl_interfaces(xwl_screen, _screen-
> >eglstreams_backend))
> +xwl_screen->egl_backend = _screen->eglstreams_backend;
> +else
> +ErrorF("Missing Wayland requirements for glamor EGL streams
> backend\n");
> }
> }
>
> @@ -191,7 +224,7 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
> return FALSE;
> }
>
> -if (!xwl_screen->egl_backend.init_egl(xwl_screen)) {
> +if (!xwl_screen->egl_backend->init_egl(xwl_screen)) {
> ErrorF("EGL setup failed, disabling glamor\n");
> return FALSE;
> }
> @@ -201,7 +234,7 @@ xwl_glamor_init(struct xwl_screen *xwl_screen)
> return FALSE;
> }
>
> -if (!xwl_screen->egl_backend.init_screen(xwl_screen)) {
> + if (!xwl_screen->egl_backend->init_screen(xwl_screen)) {
> ErrorF("E
Re: [PATCH xserver 1/3] xwayland: Add hook to check wl interface for glamor
uint32_t version); > +Bool xwl_glamor_has_wl_interface(struct xwl_screen *xwl_screen); > void xwl_glamor_post_damage(struct xwl_window *xwl_window, > PixmapPtr pixmap, RegionPtr region); > Bool xwl_glamor_allow_commits(struct xwl_window *xwl_window); -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 xserver] Xwayland: Enable EGL backend automatically
Reviewed-by: Lyude Paul
On Wed, 2018-05-30 at 11:19 +0200, Olivier Fourdan wrote:
> Check for "EGL_MESA_platform_gbm" in the avaiable EGL extensions, and
> try automatically EGL stream if not present.
>
> The command line options “-eglstream” is kept for compatibility to force
> the use of the EGL streams backend.
>
> Suggested-by: Ray Strode
> Signed-off-by: Olivier Fourdan
> ---
> v2: Use epoxy_has_egl_extension() instead of strstr() which is error prone
> as poitned out by Pekka.
>
> hw/xwayland/xwayland-glamor.c | 6 ++
> hw/xwayland/xwayland.c| 2 +-
> hw/xwayland/xwayland.h| 1 +
> 3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index f543f321d..6ae274c08 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -58,6 +58,12 @@ xwl_glamor_egl_supports_device_probing(void)
> return epoxy_has_egl_extension(NULL, "EGL_EXT_device_base");
> }
>
> +Bool
> +xwl_glamor_should_use_gbm(void)
> +{
> +return epoxy_has_egl_extension(NULL, "EGL_MESA_platform_gbm");
> +}
> +
> void **
> xwl_glamor_egl_get_devices(int *num_devices)
> {
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index a08d58451..4dd8f3810 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -939,7 +939,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
> **argv)
> struct xwl_screen *xwl_screen;
> Pixel red_mask, blue_mask, green_mask;
> int ret, bpc, green_bpc, i;
> -Bool use_eglstreams = FALSE;
> +Bool use_eglstreams = !xwl_glamor_should_use_gbm();
>
> xwl_screen = calloc(1, sizeof *xwl_screen);
> if (xwl_screen == NULL)
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index 39bc20a7e..ff746114c 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -444,6 +444,7 @@ void xwl_screen_init_xdg_output(struct xwl_screen
> *xwl_screen);
>
> void xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen);
> Bool xwl_glamor_egl_supports_device_probing(void);
> +Bool xwl_glamor_should_use_gbm(void);
> void **xwl_glamor_egl_get_devices(int *num_devices);
> Bool xwl_glamor_egl_device_has_egl_extensions(void *device,
>const char **ext_list,
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Xwayland: Enable EGL backend automatically
On Mon, 2018-05-28 at 09:11 +0200, Olivier Fourdan wrote: > Hey Luyde, > > On Fri, May 25, 2018 at 7:54 PM, Lyude Paul wrote: > > NAK, unfortunately this check isn't going to be enough, see: > > > > > > > > 2018-05-24 15:44:34 jadahl Lyude: you can also look at the globals > > sent > > > > out by the compositor > > > > 2018-05-24 15:44:52 Lyude jadahl: you mean the wl interfaces > > > > 2018-05-24 15:45:30 jadahl yes > > > > 2018-05-24 15:46:22 -- manuelschneid3r is now known as manuels > > > > 2018-05-24 15:51:02 -- manuels is now known as manuelschneid3r > > > > 2018-05-24 15:52:04 Lyude jadahl: hm. i thought that hadn't been > > working > > > > before, but something must have changed because it appears to work now > > > > 2018-05-24 15:53:03 jadahl checking for the EGL extension alone might > > not > > > > be enough anyhow, in case the compositor doesn't actually support anything > > on > > > > the other end > > > > > > > > I'm going to try to come up with a patch that uses this approach today, > > and I > > > > will include you in the CC for it > > [Adding Jonas in CC] > > Great thanks for the reviews! > > I agree that we need to check for the protocol availability of course, yet > it doesn't mean we should ditch this patch. > > Imagine (I say imagine, I do not know if that's plausible, nor if it's even > possible), some vendor pushing for EGL streams realizing they could as well > support GBM in the future, we would end up with both being supported, in > which case we should probably still prefer GBM if we were to chose > automatically. > > So, in this scenario, checking for GBM availability to decide whether or not > we should enable one or the other backend is still a good thing, > independently of the protocol availability. Oh! I should have looked closer at the patch, sorry about that-I had assumed it was checking for the EGLStream interfaces in the way that halfline had mentioned. Anyway:Reviewed-by: Lyude Paul > Hence, I think we should still consider this patch. > > Cheers, > Olivier > -- Cheers, Lyude Paul___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 5/5] xwayland: small xdg_output cleanup
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote:
> Make xwl_output_get_xdg_output() private, it doesn't need to be
> available elsewhere.
>
> Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
> ---
> hw/xwayland/xwayland-output.c | 4 +++-
> hw/xwayland/xwayland.h| 1 -
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> index 48faeb142..379062549 100644
> --- a/hw/xwayland/xwayland-output.c
> +++ b/hw/xwayland/xwayland-output.c
> @@ -38,6 +38,8 @@
> RR_Reflect_X | \
> RR_Reflect_Y)
>
> +static void xwl_output_get_xdg_output(struct xwl_output *xwl_output);
> +
> static Rotation
> wl_transform_to_xrandr(enum wl_output_transform transform)
> {
> @@ -435,7 +437,7 @@ xwl_screen_init_output(struct xwl_screen *xwl_screen)
> return TRUE;
> }
>
> -void
> +static void
> xwl_output_get_xdg_output(struct xwl_output *xwl_output)
> {
> struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index 25112e2cb..39bc20a7e 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -440,7 +440,6 @@ void xwl_present_cleanup(WindowPtr window);
>
> void xwl_screen_release_tablet_manager(struct xwl_screen *xwl_screen);
>
> -void xwl_output_get_xdg_output(struct xwl_output *xwl_output);
> void xwl_screen_init_xdg_output(struct xwl_screen *xwl_screen);
>
> void xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen);
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 xserver 4/5] xwayland: Do not disable glamor if eglstream failed
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Thu, 2018-05-24 at 16:33 +0200, Olivier Fourdan wrote:
> EGL stream requires glamor, but the opposite is not true. So if someone
> passes "-eglstream" with a GPU which does not support EGL stream, we
> could maybe still try GBM and be lucky.
>
> That allows Wayland compositor to pass "eglstream" regardless of the
> actual hardware, if they want to enable EGL stream on GPU which support
> it.
>
> Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
> ---
> v2: Try GBM only if EGL streams actually failed (or wasn't requested)
>
> hw/xwayland/xwayland.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index cc16edf27..a08d58451 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -939,9 +939,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
> **argv)
> struct xwl_screen *xwl_screen;
> Pixel red_mask, blue_mask, green_mask;
> int ret, bpc, green_bpc, i;
> -#ifdef XWL_HAS_EGLSTREAM
> Bool use_eglstreams = FALSE;
> -#endif
>
> xwl_screen = calloc(1, sizeof *xwl_screen);
> if (xwl_screen == NULL)
> @@ -998,12 +996,12 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
> **argv)
> #ifdef XWL_HAS_EGLSTREAM
> if (use_eglstreams) {
> if (!xwl_glamor_init_eglstream(xwl_screen)) {
> -ErrorF("xwayland glamor: failed to setup eglstream backend,
> falling back to swaccel\n");
> -xwl_screen->glamor = 0;
> +ErrorF("xwayland glamor: failed to setup eglstream
> backend\n");
> +use_eglstreams = FALSE;
> }
> -} else
> +}
> #endif
> -if (!xwl_glamor_init_gbm(xwl_screen)) {
> +if (!use_eglstreams && !xwl_glamor_init_gbm(xwl_screen)) {
> ErrorF("xwayland glamor: failed to setup GBM backend, falling
> back to sw accel\n");
> xwl_screen->glamor = 0;
> }
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 3/5] xwayland: process Wayland events after adding screen
Reviewed-by: Lyude Paul <ly...@redhat.com> On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote: > When we're done adding a new screen, we need to process pending Wayland > events again so that we don't end up processing xdg_output events when > unexpected if glamor is disabled (either becauase "-shm" was passed or > because "-eglstream" failed): > > Xwayland: dixGetPrivateAddr: Assertion `key->initialized' failed. > (EE) > (EE) Backtrace: > (EE) 0: Xwayland (OsSigHandler) > (EE) 1: libpthread.so.0 (funlockfile) > (EE) 2: libc.so.6 (gsignal) > (EE) 3: libc.so.6 (abort) > (EE) 4: libc.so.6 (?+0x0) > (EE) 5: libc.so.6 (__assert_fail) > (EE) 6: Xwayland (dixGetPrivateAddr) > (EE) 7: Xwayland (_fbGetWindowPixmap) > (EE) 8: Xwayland (getDrawableDamageRef) > (EE) 9: Xwayland (damageRegionProcessPending) > (EE) 10: Xwayland (damagePolyFillRect) > (EE) 11: Xwayland (miPaintWindow) > (EE) 12: Xwayland (miWindowExposures) > (EE) 13: Xwayland (miHandleValidateExposures) > (EE) 14: Xwayland (SetRootClip) > (EE) 15: Xwayland (update_screen_size) > (EE) 16: Xwayland (apply_output_change) > (EE) 17: libffi.so.6 (ffi_call_unix64) > (EE) 18: libffi.so.6 (ffi_call) > (EE) 19: libwayland-client.so.0 (wl_log_set_handler_client) > (EE) 20: libwayland-client.so.0 (_init) > (EE) 21: libwayland-client.so.0 (wl_display_dispatch_queue_pending) > (EE) 22: libwayland-client.so.0 (wl_display_roundtrip_queue) > (EE) 23: Xwayland (InitInput) > (EE) 24: Xwayland (dix_main) > (EE) 25: libc.so.6 (__libc_start_main) > (EE) 26: Xwayland (_start) > (EE) > (EE) > Fatal server error: > (EE) Caught signal 6 (Aborted). Server aborting > (EE) > Aborted (core dumped) > > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > --- > hw/xwayland/xwayland.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c > index b4049d2cc..cc16edf27 100644 > --- a/hw/xwayland/xwayland.c > +++ b/hw/xwayland/xwayland.c > @@ -1132,6 +1132,10 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char > **argv) > > AddCallback(, xwl_property_callback, pScreen); > > +wl_display_roundtrip(xwl_screen->display); > +while (xwl_screen->expecting_event) > +wl_display_roundtrip(xwl_screen->display); > + > return ret; > } > -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 2/5] xwayland: "EGL_EXT_device_base" required for eglstream
Reviewed-by: Lyude Paul <ly...@redhat.com> On Thu, 2018-05-24 at 16:11 +0200, Olivier Fourdan wrote: > eglQueryDevicesEXT() would abort if the required extenon are not > available, meaning that enabling “-eglstream”on a non-EGL stream capable > hardware would lead to an abort(). > > Check that "EGL_EXT_device_base" extension is available and baild out > early if not, so we don't abort() later. > > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > --- > hw/xwayland/xwayland-glamor.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c > index cdca072ed..f543f321d 100644 > --- a/hw/xwayland/xwayland-glamor.c > +++ b/hw/xwayland/xwayland-glamor.c > @@ -67,6 +67,9 @@ xwl_glamor_egl_get_devices(int *num_devices) > int drm_dev_count = 0; > int i; > > +if (!xwl_glamor_egl_supports_device_probing()) > +return NULL; > + > /* Get the number of devices */ > ret = eglQueryDevicesEXT(0, NULL, num_devices); > if (!ret || *num_devices < 1) -- Cheers, Lyude Paul ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/5] xwayland: Allow "-eglstream" option
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Thu, 2018-05-24 at 16:10 +0200, Olivier Fourdan wrote:
> The command line option "-eglstream" used to enable EGLi stream support
> for NVidia GPU was made available only when Xwayland was built with EGL
> stream support enabled.
>
> Wayland compositors who spawn Xwayland have no easy way to tell whether
> or not Xwayland was built with EGL stream support enabled, and adding
> "-eglstream" command line option to Xwayland when it wasn't built with
> EGL support would prevent Xwayland from starting (“Unrecognized option”
> error).
>
> Make sure we support the command line option "-eglstream" regardless of
> EGL stream support in Xwayland, obviously without EGL stream support
> this has no effect.
>
> Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
> ---
> hw/xwayland/xwayland.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index 1d6b49979..b4049d2cc 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -96,9 +96,7 @@ ddxUseMsg(void)
> ErrorF("-rootless run rootless, requires wm support\n");
> ErrorF("-wm fd create X client for wm on given fd\n");
> ErrorF("-listen fd add give fd as a listen socket\n");
> -#ifdef XWL_HAS_EGLSTREAM
> ErrorF("-eglstream use eglstream backend for nvidia
> GPUs\n");
> -#endif
> }
>
> int
> @@ -117,11 +115,9 @@ ddxProcessArgument(int argc, char *argv[], int i)
> else if (strcmp(argv[i], "-shm") == 0) {
> return 1;
> }
> -#ifdef XWL_HAS_EGLSTREAM
> else if (strcmp(argv[i], "-eglstream") == 0) {
> return 1;
> }
> -#endif
>
> return 0;
> }
> @@ -988,11 +984,13 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
> **argv)
> else if (strcmp(argv[i], "-shm") == 0) {
> xwl_screen->glamor = 0;
> }
> -#ifdef XWL_HAS_EGLSTREAM
> else if (strcmp(argv[i], "-eglstream") == 0) {
> +#ifdef XWL_HAS_EGLSTREAM
> use_eglstreams = TRUE;
> -}
> +#else
> +ErrorF("xwayland glamor: eglstream backend support not
> enabled\n");
> #endif
> +}
> }
>
> #ifdef XWL_HAS_GLAMOR
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver] Xwayland: Enable EGL backend automatically
NAK, unfortunately this check isn't going to be enough, see:
2018-05-24 15:44:34 jadahl Lyude: you can also look at the globals sent
out by the compositor
2018-05-24 15:44:52 Lyude jadahl: you mean the wl interfaces
2018-05-24 15:45:30 jadahl yes
2018-05-24 15:46:22 -- manuelschneid3r is now known as manuels
2018-05-24 15:51:02 -- manuels is now known as manuelschneid3r
2018-05-24 15:52:04 Lyude jadahl: hm. i thought that hadn't been working
before, but something must have changed because it appears to work now
2018-05-24 15:53:03 jadahl checking for the EGL extension alone might not
be enough anyhow, in case the compositor doesn't actually support anything on
the other end
I'm going to try to come up with a patch that uses this approach today, and I
will include you in the CC for it
On Fri, 2018-05-25 at 17:10 +0200, Olivier Fourdan wrote:
> Check for "platform_gbm" in the avaiable EGL extensions, and enable
> automatically EGL stream if not present.
>
> The command line options “-eglstream” is kept for compatibility to force
> the use of the EGL streams backend.
>
> Suggested-by: Ray Strode <rstr...@redhat.com>
> Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
> ---
> Note: * This was suggested by Ray Strode (halfline) in:
> https://gitlab.gnome.org/GNOME/mutter/issues/170
>* This goes on top of the previous series here:
> https://patchwork.freedesktop.org/series/43704/
>* If GBM is not supported and EGL stream wasn't enabled in Xwayland
> at build time, we even get a message from Xwayland stating that
> EGL streams backend is not enabled.
>
> hw/xwayland/xwayland-glamor.c | 7 +++
> hw/xwayland/xwayland.c| 2 +-
> hw/xwayland/xwayland.h| 1 +
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
> index f543f321d..b84c78735 100644
> --- a/hw/xwayland/xwayland-glamor.c
> +++ b/hw/xwayland/xwayland-glamor.c
> @@ -58,6 +58,13 @@ xwl_glamor_egl_supports_device_probing(void)
> return epoxy_has_egl_extension(NULL, "EGL_EXT_device_base");
> }
>
> +Bool
> +xwl_glamor_should_use_gbm(void)
> +{
> +return !!strstr((char *)eglQueryString(EGL_NO_DISPLAY, EGL_EXTENSIONS),
> +"platform_gbm");
> +}
> +
> void **
> xwl_glamor_egl_get_devices(int *num_devices)
> {
> diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
> index a08d58451..4dd8f3810 100644
> --- a/hw/xwayland/xwayland.c
> +++ b/hw/xwayland/xwayland.c
> @@ -939,7 +939,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char
> **argv)
> struct xwl_screen *xwl_screen;
> Pixel red_mask, blue_mask, green_mask;
> int ret, bpc, green_bpc, i;
> -Bool use_eglstreams = FALSE;
> +Bool use_eglstreams = !xwl_glamor_should_use_gbm();
>
> xwl_screen = calloc(1, sizeof *xwl_screen);
> if (xwl_screen == NULL)
> diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
> index 39bc20a7e..ff746114c 100644
> --- a/hw/xwayland/xwayland.h
> +++ b/hw/xwayland/xwayland.h
> @@ -444,6 +444,7 @@ void xwl_screen_init_xdg_output(struct xwl_screen
> *xwl_screen);
>
> void xwl_glamor_egl_make_current(struct xwl_screen *xwl_screen);
> Bool xwl_glamor_egl_supports_device_probing(void);
> +Bool xwl_glamor_should_use_gbm(void);
> void **xwl_glamor_egl_get_devices(int *num_devices);
> Bool xwl_glamor_egl_device_has_egl_extensions(void *device,
>const char **ext_list,
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/3] xwayland: Decouple GBM from glamor
On Tue, 2018-04-24 at 10:35 +0100, Daniel Stone wrote:
> Hi,
>
> On 20 April 2018 at 19:38, Adam Jackson <a...@redhat.com> wrote:
> > This takes all of the gbm related code in wayland-glamor.c and moves it
> > into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> > Additionally, we add the egl_backend struct into xwl_screen in order to
> > provide hooks for alternative EGL backends such as nvidia's EGLStreams.
>
> I do think the end result of this commit is better; there are a lot of
> good cleanups in here. It would be much easier to review next time
> though, if this was broken into a few separate commits. There is mass
> code motion, resequencing of functions, reordering of struct members,
> minor changes of struct declarations (e.g. void * -> EGLImage in
> xwl_pixmap), a lot of formatting changes, and other cleanups like
> moving variable declarations into child blocks. It's taken until now
> to review it because I've got four panes open with new and old code
> side by side, with quite a lot of back and forth.
>
> > +_X_EXPORT Bool
> > +glamor_get_formats(ScreenPtr screen,
> > + CARD32 *num_formats, CARD32 **formats)
> > +{
> > +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> > +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > +int i;
> > +
> > +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> > +return FALSE;
> > +
> > +if (xwl_screen->num_formats == 0) {
> > + *num_formats = 0;
> > + return TRUE;
> > +}
>
> Changes from ac48724639e0a6a9e421b3b4e545d8506fd6bf5dost in rebase.
>
> > +_X_EXPORT Bool
> > +glamor_get_modifiers(ScreenPtr screen, CARD32 format,
> > + CARD32 *num_modifiers, uint64_t **modifiers)
> > +{
> > +struct xwl_screen *xwl_screen = xwl_screen_get(screen);
> > +struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > +struct xwl_format *xwl_format = NULL;
> > +int i;
> > +
> > +if (!xwl_gbm->dmabuf_capable || !xwl_gbm->dmabuf)
> > +return FALSE;
> > +
> > +/* Explicitly zero the count as the caller may ignore the return
> > value */
> > +*num_modifiers = 0;
>
> Changes from b36a14c0b0e7e38406622eb5ff0666a8b8bc50f4 misplaced in rebase.
>
> > +static void
> > +xwl_drm_handle_device(void *data, struct wl_drm *drm, const char *device)
> > +{
> > + struct xwl_screen *xwl_screen = data;
> > + struct xwl_gbm_private *xwl_gbm = xwl_gbm_get(xwl_screen);
> > + drm_magic_t magic;
> > +
> > + xwl_gbm->device_name = strdup(device);
> > + if (!xwl_gbm->device_name) {
> > + xwl_glamor_gbm_cleanup(xwl_screen);
> > + return;
> > + }
> > +
> > + xwl_gbm->drm_fd = open(xwl_gbm->device_name, O_RDWR | O_CLOEXEC);
> > + if (xwl_gbm->drm_fd == -1) {
> > + ErrorF("wayland-egl: could not open %s (%s)\n",
> > + xwl_gbm->device_name, strerror(errno));
> > + xwl_glamor_gbm_cleanup(xwl_screen);
> > + return;
> > + }
> > +
> > + if (is_fd_render_node(xwl_gbm->drm_fd)) {
> > + xwl_gbm->fd_render_node = 1;
> > + xwl_screen->expecting_event--;
> > + } else {
> > + drmGetMagic(xwl_gbm->drm_fd, );
> > + wl_drm_authenticate(xwl_gbm->drm, magic);
> > + }
> > +}
>
> e.g. here, the change to expecting_event is unnecessary; the previous
> code explicitly decremented and re-incremented to make it clear which
> event was which, and the change meant I had to double back and read
> through the whole init flow again. The current code is still correct,
> and I don't care enough to ask for it to be made back the way it was,
> but in future please try to keep these kinds of subtle changes
> separate from mass code motion.
Will keep that in mind for the future, thanks!
>
> The rest is:
> Reviewed-by: Daniel Stone <dani...@collabora.com>
>
> Cheers,
> Daniel
--
Cheers,
Lyude Paul
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xserver 1/3] xwayland: Decouple GBM from glamor
lgtm! for the whole series:
Reviewed-by: Lyude Paul <ly...@redhat.com>
On Fri, 2018-04-20 at 14:38 -0400, Adam Jackson wrote:
> From: Lyude Paul <ly...@redhat.com>
>
> This takes all of the gbm related code in wayland-glamor.c and moves it
> into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
> Additionally, we add the egl_backend struct into xwl_screen in order to
> provide hooks for alternative EGL backends such as nvidia's EGLStreams.
>
> Signed-off-by: Lyude Paul <ly...@redhat.com>
> ---
> hw/xwayland/Makefile.am | 1 +
> hw/xwayland/meson.build | 6 +-
> hw/xwayland/xwayland-glamor-gbm.c | 892 ++
> hw/xwayland/xwayland-glamor.c | 760 +
> hw/xwayland/xwayland.c| 17 +-
> hw/xwayland/xwayland.h| 58 +-
> 6 files changed, 976 insertions(+), 758 deletions(-)
> create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
>
> diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
> index 80d3a1f199..3fd980d0ee 100644
> --- a/hw/xwayland/Makefile.am
> +++ b/hw/xwayland/Makefile.am
> @@ -35,6 +35,7 @@ Xwayland_built_sources =
> if GLAMOR_EGL
> Xwayland_SOURCES += \
> xwayland-glamor.c \
> + xwayland-glamor-gbm.c \
> xwayland-present.c
> if XV
> Xwayland_SOURCES += \
> diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
> index 8d178825e7..ef4379aab0 100644
> --- a/hw/xwayland/meson.build
> +++ b/hw/xwayland/meson.build
> @@ -52,7 +52,11 @@ srcs += code.process(dmabuf_xml)
>
> xwayland_glamor = []
> if gbm_dep.found()
> -srcs += [ 'xwayland-glamor.c', 'xwayland-present.c' ]
> +srcs += [
> +'xwayland-glamor.c',
> +'xwayland-glamor-gbm.c',
> +'xwayland-present.c',
> +]
> if build_xv
> srcs += 'xwayland-glamor-xv.c'
> endif
> diff --git a/hw/xwayland/xwayland-glamor-gbm.c b/hw/xwayland/xwayland-
> glamor-gbm.c
> new file mode 100644
> index 00..7be1437e86
> --- /dev/null
> +++ b/hw/xwayland/xwayland-glamor-gbm.c
> @@ -0,0 +1,892 @@
> +/*
> + * Copyright © 2011-2014 Intel Corporation
> + * Copyright © 2017 Red Hat Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use, copy,
> + * modify, merge, publish, distribute, sublicense, and/or sell copies
> + * of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including
> + * the next paragraph) shall be included in all copies or substantial
> + * portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + *
> + * Authors:
> + *Lyude Paul <ly...@redhat.com>
> + *
> + */
> +
> +#include "xwayland.h"
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define MESA_EGL_NO_X11_HEADERS
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include "drm-client-protocol.h"
> +
> +struct xwl_gbm_private {
> +char *device_name;
> +struct gbm_device *gbm;
> +struct wl_drm *drm;
> +struct zwp_linux_dmabuf_v1 *dmabuf;
> +int drm_fd;
> +int fd_render_node;
> +Bool drm_authenticated;
> +uint32_t capabilities;
> +int dmabuf_capable;
> +};
> +
> +struct xwl_pixmap {
> +struct wl_buffer *buffer;
> +EGLImage image;
> +unsigned int texture;
> +struct gbm_bo *bo;
> +};
> +
> +static DevPrivateKeyRec xwl_gbm_private_key;
> +static DevPrivateKeyRec xwl_auth_state_private_key;
> +
> +static inline struct xwl_gbm_private *
> +xwl_gbm_get(struct xwl_screen *xwl_screen)
> +{
> +return dixLookupPrivate(_screen->screen->devPrivates,
> +_gbm_private_key);
> +}
> +
> +static uint32_t
> +gbm_f
[PATCH xserver] meson: Ensure we always build Xext/hashtable.c for glx
Seems that while glxvnd relies on some of the hashtable functions in
Xext, we only build hashtable support for Xext if we're also building
the res extension. This leads to some errors if you try to build glx
without res enabled:
glx/liblibglxvnd.a(vndcmds.c.o): In function `LookupVendorPrivDispatch':
/home/lyudess/Projects/xserver/glx/vndcmds.c:65: undefined reference to
`ht_find'
/home/lyudess/Projects/xserver/glx/vndcmds.c:67: undefined reference to `ht_add'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchInit':
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_generic_compare'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_generic_hash'
/home/lyudess/Projects/xserver/glx/vndcmds.c:405: undefined reference to
`ht_create'
glx/liblibglxvnd.a(vndcmds.c.o): In function `GlxDispatchReset':
/home/lyudess/Projects/xserver/glx/vndcmds.c:468: undefined reference to
`ht_destroy'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
So, make sure that hashtable.c gets both for both glx and res
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
Xext/meson.build | 6 +-
meson.build | 9 +
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Xext/meson.build b/Xext/meson.build
index a72173718..7727e207e 100644
--- a/Xext/meson.build
+++ b/Xext/meson.build
@@ -23,8 +23,12 @@ if build_mitshm
hdrs_xext += ['shmint.h']
endif
+if build_hashtable
+srcs_xext += 'hashtable.c'
+endif
+
if build_res
-srcs_xext += ['hashtable.c', 'xres.c']
+srcs_xext += 'xres.c'
endif
if build_screensaver
diff --git a/meson.build b/meson.build
index e2dad87bb..5e794ccd0 100644
--- a/meson.build
+++ b/meson.build
@@ -96,6 +96,8 @@ nettle_dep = dependency('nettle')
dbus_required = get_option('systemd_logind') == 'true'
dbus_dep = dependency('dbus-1', version: '>= 1.0', required: dbus_required)
+build_hashtable = false
+
# Resolve default values of some options
xkb_dir = get_option('xkb_dir')
if xkb_dir == ''
@@ -300,6 +302,9 @@ if not xdmcp_dep.found()
endif
build_glx = get_option('glx')
+if build_glx
+build_hashtable = true
+endif
libdrm_dep = dependency('libdrm', version: '>= 2.4.89', required: false)
@@ -363,6 +368,10 @@ endif
build_xf86bigfont = get_option('xf86bigfont')
build_screensaver = get_option('screensaver')
build_res = get_option('xres')
+if build_res
+build_hashtable = true
+endif
+
build_xace = get_option('xace')
build_xinerama = get_option('xinerama')
--
2.14.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] meson: Fix indenting in glx/meson.build
No functional changes, just fixing a tabs vs. space error I noticed
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
glx/meson.build | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/glx/meson.build b/glx/meson.build
index dc7aab962..69d558e78 100644
--- a/glx/meson.build
+++ b/glx/meson.build
@@ -68,8 +68,8 @@ hdrs_vnd = [
libglxvnd = ''
if build_glx
libglxvnd = static_library('libglxvnd',
- srcs_vnd,
- include_directories: inc,
+srcs_vnd,
+include_directories: inc,
dependencies: [
common_dep,
dl_dep,
--
2.14.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC v3 0/3] xwayland: Add support for eglstreams
Some changes since the last version: - Get rid of some unecessary context switches - Remove EGLSurface from current context on deletion with eglMakeCurrent() since an EGLSurface can stay around after deletion for as long as it's current - Use EGL_CONTEXT_PRIORITY_LEVEL_IMG to set our rendering priority to high, speeds things up a tiny bit more. Lyude Paul (3): xwayland: Decouple GBM from glamor xwayland: Add xwayland-config.h xwayland: Add glamor egl_backend for EGLStreams configure.ac| 31 ++ hw/xwayland/Makefile.am | 26 +- hw/xwayland/meson.build | 18 +- hw/xwayland/xwayland-glamor-eglstream.c | 824 hw/xwayland/xwayland-glamor-gbm.c | 628 hw/xwayland/xwayland-glamor.c | 577 +- hw/xwayland/xwayland.c | 57 ++- hw/xwayland/xwayland.h | 95 +++- include/meson.build | 10 +- include/xwayland-config.h.in| 13 + include/xwayland-config.h.meson.in | 11 + meson.build | 15 + meson_options.txt | 2 + 13 files changed, 1816 insertions(+), 491 deletions(-) create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c create mode 100644 hw/xwayland/xwayland-glamor-gbm.c create mode 100644 include/xwayland-config.h.in create mode 100644 include/xwayland-config.h.meson.in -- 2.14.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC v3 3/3] xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through the use of EGLStreams and nvidia's custom wayland protocol by adding another egl_backend driver. This also adds some additional egl_backend hooks that are required to make things work properly. EGLStreams work a lot differently then the traditional way of handling buffers with wayland. Unfortunately, there are also a LOT of various pitfalls baked into it's design that need to be explained. This has a very large and unfortunate implication: direct rendering is, for the time being at least, impossible to do through EGLStreams. The main reason being that the EGLStream spec mandates that we lose the entire color buffer contents with each eglSwapBuffers(), which goes against X's requirement of not losing data with pixmaps. no way to use an allocated EGLSurface as the storage for glamor rendering like we do with GBM, we have to rely on blitting each pixmap to it's respective EGLSurface producer each frame. In order to pull this off, we add two different additional egl_backend hooks that GBM opts out of implementing: - egl_backend.allow_commits for holding off displaying any EGLStream backed pixmaps until the point where it's stream is completely initialized and ready for use - egl_backend.post_damage for blitting the content of the EGLStream surface producer before Xwayland actually damages and commits the wl_surface to the screen. The other big pitfall here is that using nvidia's wayland-eglstreams helper library is also not possible for the most part. All of it's API for creating and destroying streams rely on being able to perform a roundtrip in order to bring each stream to completion since the wayland compositor must perform it's job of connecting a consumer to each EGLstream. Because Xwayland has to potentially handle both responding to the wayland compositor and it's own X clients, the situation of the wayland compositor being one of our X clients must be considered. If we perform a roundtrip with the Wayland compositor, it's possible that the wayland compositor might currently be connected to us as an X client and thus hang while both Xwayland and the wayland compositor await responses from eachother. To avoid this, we work directly with the wayland protocol and use wl_display_sync() events along with release() events to set up and destroy EGLStreams asynchronously alongside handling X clients. Additionally, since setting up EGLStreams is not an atomic operation we have to take into consideration the fact that an EGLStream can potentially be created in response to a window resize, then immediately deleted due to another pending window resize in the same X client's pending reqests before Xwayland hits the part of it's event loop where we read from the wayland compositor. To make this even more painful, we also have to take into consideration that since EGLStreams are not atomic that it's possible we could delete wayland resources for an EGLStream before the compositor even finishes using them and thus run into errors. So, we use quite a bit of tracking logic to keep EGLStream objects alive until we know the compositor isn't using them (even if this means the stream outlives the pixmap it backed). While the default backend for glamor remains GBM, this patch exists for users who have had to deal with the reprecussion of their GPU manufacturers ignoring the advice of upstream and the standardization of GBM across most major GPU manufacturers. It is not intended to be a final solution to the GBM debate, but merely a baindaid so our users don't have to suffer from the consequences of companies avoiding working upstream. New drivers are strongly encouraged not to use this as a backend, and use GBM like everyone else. We even spit this out as an error from Xwayland when using the eglstream backend. Signed-off-by: Lyude Paul <ly...@redhat.com> --- configure.ac| 24 + hw/xwayland/Makefile.am | 23 +- hw/xwayland/meson.build | 19 +- hw/xwayland/xwayland-glamor-eglstream.c | 824 hw/xwayland/xwayland-glamor-gbm.c | 6 +- hw/xwayland/xwayland-glamor.c | 111 - hw/xwayland/xwayland.c | 34 ++ hw/xwayland/xwayland.h | 39 ++ include/meson.build | 5 +- include/xwayland-config.h.in| 3 + include/xwayland-config.h.meson.in | 3 + meson.build | 15 + meson_options.txt | 2 + 13 files changed, 1096 insertions(+), 12 deletions(-) create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c diff --git a/configure.ac b/configure.ac index e4c2965d6..c8d46a075 100644 --- a/configure.ac +++ b/configure.ac @@ -590,6 +590,7 @@ AC_ARG_ENABLE(xvfb, AS_HELP_STRING([--enable-xvfb], [Build Xvfb server AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build
[RFC v3 1/3] xwayland: Decouple GBM from glamor
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 632 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c| 13 +-
hw/xwayland/xwayland.h| 54 +++-
6 files changed, 705 insertions(+), 498 deletions(-)
create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 7204591e3..d9e9fe8b6 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -33,7 +33,8 @@ Xwayland_built_sources =
if GLAMOR_EGL
Xwayland_SOURCES +=\
- xwayland-glamor.c
+ xwayland-glamor.c \
+ xwayland-glamor-gbm.c
if XV
Xwayland_SOURCES +=\
xwayland-glamor-xv.c
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index 24203c63e..d219e2f44 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -43,6 +43,7 @@ srcs += code.process(xdg_output_xml)
xwayland_glamor = []
if gbm_dep.found()
srcs += 'xwayland-glamor.c'
+srcs += 'xwayland-glamor-gbm.c'
if build_xv
srcs += 'xwayland-glamor-xv.c'
endif
diff --git a/hw/xwayland/xwayland-glamor-gbm.c
b/hw/xwayland/xwayland-glamor-gbm.c
new file mode 100644
index 0..4b973019f
--- /dev/null
+++ b/hw/xwayland/xwayland-glamor-gbm.c
@@ -0,0 +1,632 @@
+/*
+ * Copyright © 2011-2014 Intel Corporation
+ * Copyright © 2017 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Lyude Paul <ly...@redhat.com>
+ *
+ */
+
+#include "xwayland.h"
+
+#include
+#include
+#include
+
+#define MESA_EGL_NO_X11_HEADERS
+#include
+#include
+
+#include
+#include
+#include
+#include "drm-client-protocol.h"
+
+struct xwl_gbm_private {
+struct gbm_device *gbm;
+struct wl_drm *drm;
+char *device_name;
+int drm_fd;
+int fd_render_node;
+Bool drm_authenticated;
+uint32_t capabilities;
+};
+
+struct xwl_pixmap {
+struct wl_buffer *buffer;
+EGLImage image;
+unsigned int texture;
+struct gbm_bo *bo;
+};
+
+static DevPrivateKeyRec xwl_gbm_private_key;
+static DevPrivateKeyRec xwl_auth_state_private_key;
+
+static inline struct xwl_gbm_private *
+xwl_gbm_get(struct xwl_screen *xwl_screen)
+{
+return dixLookupPrivate(_screen->screen->devPrivates,
+_gbm_private_key);
+}
+
+static uint32_t
+gbm_format_for_depth(int depth)
+{
+switch (depth) {
+case 16:
+return GBM_FORMAT_RGB565;
+case 24:
+return GBM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return GBM_FORMAT_ARGB;
+}
+}
+
+static uint32_t
+drm_format_for_depth(int depth)
+{
+switch (depth) {
+case 15:
+return WL_DRM_FORMAT_XRGB1555;
+case 16:
+return WL_DRM_FORMAT_RGB565;
+case 24:
+return WL_DRM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return WL_DRM_FORMAT_ARGB;
+}
+}
+
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, ))
+return 0;
+if (!S_ISCHR(render.st_mode))
+return 0;
+if (render.st_rdev & 0x80)
+return 1;
+
+return 0;
+}
+
+static PixmapPtr
+xwl_glamor_gbm_create_pixmap_for_bo(ScreenPtr screen, st
[RFC v3 2/3] xwayland: Add xwayland-config.h
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build| 7 +++
include/xwayland-config.h.in | 10 ++
include/xwayland-config.h.meson.in | 8
6 files changed, 39 insertions(+), 5 deletions(-)
create mode 100644 include/xwayland-config.h.in
create mode 100644 include/xwayland-config.h.meson.in
diff --git a/configure.ac b/configure.ac
index 98b8ea2ed..e4c2965d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,8 @@ dnl xkb-config.h covers XKB for the Xorg and Xnest DDXs.
AC_CONFIG_HEADERS(include/xkb-config.h)
dnl xwin-config.h covers the XWin DDX.
AC_CONFIG_HEADERS(include/xwin-config.h)
+dnl xwayland-config.h covers Xwayland.
+AC_CONFIG_HEADERS(include/xwayland-config.h)
dnl version-config.h covers the version numbers so they can be bumped without
dnl forcing an entire recompile.x
AC_CONFIG_HEADERS(include/version-config.h)
@@ -2373,6 +2375,11 @@ if test "x$XWAYLAND" = xyes; then
AC_MSG_ERROR([Xwayland build explicitly requested, but required
modules not found.])
fi
+ if test "x$GLAMOR" = xyes && test "x$GBM" = xyes; then
+ AC_DEFINE(XWL_HAS_GLAMOR, 1,
+ [Build xwayland with glamor support])
+ fi
+
XWAYLAND_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB
$RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB
$MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB
$XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
XWAYLAND_SYS_LIBS="$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS"
AC_SUBST([XWAYLAND_LIBS])
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 979b72918..f4a9a0615 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -647,7 +647,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
region = DamageRegion(xwl_window->damage);
pixmap = (*xwl_screen->screen->GetWindowPixmap) (xwl_window->window);
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor)
buffer = xwl_glamor_pixmap_get_wl_buffer(pixmap);
else
@@ -725,7 +725,7 @@ registry_global(void *data, struct wl_registry *registry,
uint32_t id,
wl_registry_bind(registry, id, _output_manager_v1_interface,
1);
xwl_screen_init_xdg_output(xwl_screen);
}
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
else if (xwl_screen->glamor) {
xwl_glamor_init_wl_registry(xwl_screen, registry, id, interface,
version);
@@ -909,7 +909,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
dixSetPrivate(>devPrivates, _screen_private_key, xwl_screen);
xwl_screen->screen = pScreen;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
xwl_screen->glamor = 1;
#endif
@@ -937,12 +937,14 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
}
}
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor) {
if (!xwl_glamor_init_gbm(xwl_screen)) {
ErrorF("xwayland glamor: failed to setup GBM backend, falling back
to sw accel\n");
xwl_screen->glamor = 0;
}
}
+#endif
/* In rootless mode, we don't have any screen storage, and the only
* rendering should be to redirected mode. */
@@ -1026,7 +1028,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
if (!xwl_screen_init_cursor(xwl_screen))
return FALSE;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor && !xwl_glamor_init(xwl_screen)) {
ErrorF("Failed to initialize glamor, falling back to sw\n");
xwl_screen->glamor = 0;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 88e9ec832..7961cc6f1 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -26,7 +26,7 @@
#ifndef XWAYLAND_H
#define XWAYLAND_H
-#include
+#include
#include
#include
diff --git a/include/meson.build b/include/meson.build
index 00ec0573d..a5701fc53 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -293,6 +293,13 @@ configure_file(output : 'xwin-config.h',
input : 'xwin-config.h.meson.in',
configuration : xwin_data)
+xwayland_data = configuration_data()
+xwayland_data.set('XWL_HAS_GLAMOR', build_glamor and gbm_dep.found())
+
+configure_file(output : 'xwayland-config.h',
+ input : 'xwayland-config.h.meson.in',
+ configuration : xwayland_data)
+
if build_xorg
install_data(
[
diff --git a/include/xwayland-config.h.in b/include/xwayland-config.h.in
new fil
[RFC v2 0/3] xwayland: Add support for eglstreams
Some changes:
- I broke GBM by accident in v1 by not making sure that we setup wl_drm
in xwl_glamor_gbm_init_wl_registry() by incrementing
xwl_screen->expecting_event in xwl_glamor_gbm_init_wl_registry()
properly and decrementing it in the wl_drm handlers. So now we don't
break that.
- Fixed up the commit message for adding EGLStreams in response to
ajax's comments
As well, like ajax asked here's some benchmarks of how well this works:
(keep in mind, nouveau is at max pstate here since otherwise it performs
terribly)
1: nouveau-gbm.log
2: nouveau-shm.log
3: nv-eglstream.log
4: nv-shm.log
1 2 3 4Operation
-
63800.0 23500.0 27600.0 27100.0 Copy 500x500 from pixmap to window
Unfortunately, not that great :(
Lyude Paul (3):
xwayland: Decouple GBM from glamor
xwayland: Add xwayland-config.h
xwayland: Add glamor egl_backend for EGLStreams
configure.ac| 31 ++
hw/xwayland/Makefile.am | 26 +-
hw/xwayland/meson.build | 18 +-
hw/xwayland/xwayland-glamor-eglstream.c | 813
hw/xwayland/xwayland-glamor-gbm.c | 628
hw/xwayland/xwayland-glamor.c | 577 +--
hw/xwayland/xwayland.c | 57 ++-
hw/xwayland/xwayland.h | 95 +++-
include/meson.build | 10 +-
include/xwayland-config.h.in| 13 +
include/xwayland-config.h.meson.in | 11 +
meson.build | 15 +
meson_options.txt | 2 +
13 files changed, 1805 insertions(+), 491 deletions(-)
create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c
create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
create mode 100644 include/xwayland-config.h.in
create mode 100644 include/xwayland-config.h.meson.in
--
2.14.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[RFC v2 2/3] xwayland: Add xwayland-config.h
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build| 7 +++
include/xwayland-config.h.in | 10 ++
include/xwayland-config.h.meson.in | 8
6 files changed, 39 insertions(+), 5 deletions(-)
create mode 100644 include/xwayland-config.h.in
create mode 100644 include/xwayland-config.h.meson.in
diff --git a/configure.ac b/configure.ac
index 98b8ea2ed..e4c2965d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,8 @@ dnl xkb-config.h covers XKB for the Xorg and Xnest DDXs.
AC_CONFIG_HEADERS(include/xkb-config.h)
dnl xwin-config.h covers the XWin DDX.
AC_CONFIG_HEADERS(include/xwin-config.h)
+dnl xwayland-config.h covers Xwayland.
+AC_CONFIG_HEADERS(include/xwayland-config.h)
dnl version-config.h covers the version numbers so they can be bumped without
dnl forcing an entire recompile.x
AC_CONFIG_HEADERS(include/version-config.h)
@@ -2373,6 +2375,11 @@ if test "x$XWAYLAND" = xyes; then
AC_MSG_ERROR([Xwayland build explicitly requested, but required
modules not found.])
fi
+ if test "x$GLAMOR" = xyes && test "x$GBM" = xyes; then
+ AC_DEFINE(XWL_HAS_GLAMOR, 1,
+ [Build xwayland with glamor support])
+ fi
+
XWAYLAND_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB
$RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB
$MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB
$XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
XWAYLAND_SYS_LIBS="$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS"
AC_SUBST([XWAYLAND_LIBS])
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 979b72918..f4a9a0615 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -647,7 +647,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
region = DamageRegion(xwl_window->damage);
pixmap = (*xwl_screen->screen->GetWindowPixmap) (xwl_window->window);
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor)
buffer = xwl_glamor_pixmap_get_wl_buffer(pixmap);
else
@@ -725,7 +725,7 @@ registry_global(void *data, struct wl_registry *registry,
uint32_t id,
wl_registry_bind(registry, id, _output_manager_v1_interface,
1);
xwl_screen_init_xdg_output(xwl_screen);
}
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
else if (xwl_screen->glamor) {
xwl_glamor_init_wl_registry(xwl_screen, registry, id, interface,
version);
@@ -909,7 +909,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
dixSetPrivate(>devPrivates, _screen_private_key, xwl_screen);
xwl_screen->screen = pScreen;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
xwl_screen->glamor = 1;
#endif
@@ -937,12 +937,14 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
}
}
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor) {
if (!xwl_glamor_init_gbm(xwl_screen)) {
ErrorF("xwayland glamor: failed to setup GBM backend, falling back
to sw accel\n");
xwl_screen->glamor = 0;
}
}
+#endif
/* In rootless mode, we don't have any screen storage, and the only
* rendering should be to redirected mode. */
@@ -1026,7 +1028,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
if (!xwl_screen_init_cursor(xwl_screen))
return FALSE;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor && !xwl_glamor_init(xwl_screen)) {
ErrorF("Failed to initialize glamor, falling back to sw\n");
xwl_screen->glamor = 0;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 88e9ec832..7961cc6f1 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -26,7 +26,7 @@
#ifndef XWAYLAND_H
#define XWAYLAND_H
-#include
+#include
#include
#include
diff --git a/include/meson.build b/include/meson.build
index 00ec0573d..a5701fc53 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -293,6 +293,13 @@ configure_file(output : 'xwin-config.h',
input : 'xwin-config.h.meson.in',
configuration : xwin_data)
+xwayland_data = configuration_data()
+xwayland_data.set('XWL_HAS_GLAMOR', build_glamor and gbm_dep.found())
+
+configure_file(output : 'xwayland-config.h',
+ input : 'xwayland-config.h.meson.in',
+ configuration : xwayland_data)
+
if build_xorg
install_data(
[
diff --git a/include/xwayland-config.h.in b/include/xwayland-config.h.in
new fil
[RFC v2 1/3] xwayland: Decouple GBM from glamor
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 632 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c| 13 +-
hw/xwayland/xwayland.h| 54 +++-
6 files changed, 705 insertions(+), 498 deletions(-)
create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 7204591e3..d9e9fe8b6 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -33,7 +33,8 @@ Xwayland_built_sources =
if GLAMOR_EGL
Xwayland_SOURCES +=\
- xwayland-glamor.c
+ xwayland-glamor.c \
+ xwayland-glamor-gbm.c
if XV
Xwayland_SOURCES +=\
xwayland-glamor-xv.c
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index 24203c63e..d219e2f44 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -43,6 +43,7 @@ srcs += code.process(xdg_output_xml)
xwayland_glamor = []
if gbm_dep.found()
srcs += 'xwayland-glamor.c'
+srcs += 'xwayland-glamor-gbm.c'
if build_xv
srcs += 'xwayland-glamor-xv.c'
endif
diff --git a/hw/xwayland/xwayland-glamor-gbm.c
b/hw/xwayland/xwayland-glamor-gbm.c
new file mode 100644
index 0..4b973019f
--- /dev/null
+++ b/hw/xwayland/xwayland-glamor-gbm.c
@@ -0,0 +1,632 @@
+/*
+ * Copyright © 2011-2014 Intel Corporation
+ * Copyright © 2017 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Lyude Paul <ly...@redhat.com>
+ *
+ */
+
+#include "xwayland.h"
+
+#include
+#include
+#include
+
+#define MESA_EGL_NO_X11_HEADERS
+#include
+#include
+
+#include
+#include
+#include
+#include "drm-client-protocol.h"
+
+struct xwl_gbm_private {
+struct gbm_device *gbm;
+struct wl_drm *drm;
+char *device_name;
+int drm_fd;
+int fd_render_node;
+Bool drm_authenticated;
+uint32_t capabilities;
+};
+
+struct xwl_pixmap {
+struct wl_buffer *buffer;
+EGLImage image;
+unsigned int texture;
+struct gbm_bo *bo;
+};
+
+static DevPrivateKeyRec xwl_gbm_private_key;
+static DevPrivateKeyRec xwl_auth_state_private_key;
+
+static inline struct xwl_gbm_private *
+xwl_gbm_get(struct xwl_screen *xwl_screen)
+{
+return dixLookupPrivate(_screen->screen->devPrivates,
+_gbm_private_key);
+}
+
+static uint32_t
+gbm_format_for_depth(int depth)
+{
+switch (depth) {
+case 16:
+return GBM_FORMAT_RGB565;
+case 24:
+return GBM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return GBM_FORMAT_ARGB;
+}
+}
+
+static uint32_t
+drm_format_for_depth(int depth)
+{
+switch (depth) {
+case 15:
+return WL_DRM_FORMAT_XRGB1555;
+case 16:
+return WL_DRM_FORMAT_RGB565;
+case 24:
+return WL_DRM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return WL_DRM_FORMAT_ARGB;
+}
+}
+
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, ))
+return 0;
+if (!S_ISCHR(render.st_mode))
+return 0;
+if (render.st_rdev & 0x80)
+return 1;
+
+return 0;
+}
+
+static PixmapPtr
+xwl_glamor_gbm_create_pixmap_for_bo(ScreenPtr screen, st
[RFC v2 3/3] xwayland: Add glamor egl_backend for EGLStreams
This adds initial support for displaying Xwayland applications through the use of EGLStreams and nvidia's custom wayland protocol by adding another egl_backend driver. This also adds some additional egl_backend hooks that are required to make things work properly. EGLStreams work a lot differently then the traditional way of handling buffers with wayland. Unfortunately, there are also a LOT of various pitfalls baked into it's design that need to be explained. This has a very large and unfortunate implication: direct rendering is, for the time being at least, impossible to do through EGLStreams. The main reason being that the EGLStream spec mandates that we lose the entire color buffer contents with each eglSwapBuffers(), which goes against X's requirement of not losing data with pixmaps. no way to use an allocated EGLSurface as the storage for glamor rendering like we do with GBM, we have to rely on blitting each pixmap to it's respective EGLSurface producer each frame. In order to pull this off, we add two different additional egl_backend hooks that GBM opts out of implementing: - egl_backend.allow_commits for holding off displaying any EGLStream backed pixmaps until the point where it's stream is completely initialized and ready for use - egl_backend.post_damage for blitting the content of the EGLStream surface producer before Xwayland actually damages and commits the wl_surface to the screen. The other big pitfall here is that using nvidia's wayland-eglstreams helper library is also not possible for the most part. All of it's API for creating and destroying streams rely on being able to perform a roundtrip in order to bring each stream to completion since the wayland compositor must perform it's job of connecting a consumer to each EGLstream. Because Xwayland has to potentially handle both responding to the wayland compositor and it's own X clients, the situation of the wayland compositor being one of our X clients must be considered. If we perform a roundtrip with the Wayland compositor, it's possible that the wayland compositor might currently be connected to us as an X client and thus hang while both Xwayland and the wayland compositor await responses from eachother. To avoid this, we work directly with the wayland protocol and use wl_display_sync() events along with release() events to set up and destroy EGLStreams asynchronously alongside handling X clients. Additionally, since setting up EGLStreams is not an atomic operation we have to take into consideration the fact that an EGLStream can potentially be created in response to a window resize, then immediately deleted due to another pending window resize in the same X client's pending reqests before Xwayland hits the part of it's event loop where we read from the wayland compositor. To make this even more painful, we also have to take into consideration that since EGLStreams are not atomic that it's possible we could delete wayland resources for an EGLStream before the compositor even finishes using them and thus run into errors. So, we use quite a bit of tracking logic to keep EGLStream objects alive until we know the compositor isn't using them (even if this means the stream outlives the pixmap it backed). While the default backend for glamor remains GBM, this patch exists for users who have had to deal with the reprecussion of their GPU manufacturers ignoring the advice of upstream and the standardization of GBM across most major GPU manufacturers. It is not intended to be a final solution to the GBM debate, but merely a baindaid so our users don't have to suffer from the consequences of companies avoiding working upstream. New drivers are strongly encouraged not to use this as a backend, and use GBM like everyone else. We even spit this out as an error from Xwayland when using the eglstream backend. Signed-off-by: Lyude Paul <ly...@redhat.com> --- configure.ac| 24 + hw/xwayland/Makefile.am | 23 +- hw/xwayland/meson.build | 19 +- hw/xwayland/xwayland-glamor-eglstream.c | 813 hw/xwayland/xwayland-glamor-gbm.c | 6 +- hw/xwayland/xwayland-glamor.c | 111 - hw/xwayland/xwayland.c | 34 ++ hw/xwayland/xwayland.h | 39 ++ include/meson.build | 5 +- include/xwayland-config.h.in| 3 + include/xwayland-config.h.meson.in | 3 + meson.build | 15 + meson_options.txt | 2 + 13 files changed, 1085 insertions(+), 12 deletions(-) create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c diff --git a/configure.ac b/configure.ac index e4c2965d6..c8d46a075 100644 --- a/configure.ac +++ b/configure.ac @@ -590,6 +590,7 @@ AC_ARG_ENABLE(xvfb, AS_HELP_STRING([--enable-xvfb], [Build Xvfb server AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build
[RFC 3/3] xwayland: Add glamor egl_backend for EGLStreams
. Signed-off-by: Lyude Paul <ly...@redhat.com> --- configure.ac| 24 + hw/xwayland/Makefile.am | 23 +- hw/xwayland/meson.build | 19 +- hw/xwayland/xwayland-glamor-eglstream.c | 813 hw/xwayland/xwayland-glamor-gbm.c | 6 +- hw/xwayland/xwayland-glamor.c | 111 - hw/xwayland/xwayland.c | 34 ++ hw/xwayland/xwayland.h | 39 ++ include/meson.build | 5 +- include/xwayland-config.h.in| 3 + include/xwayland-config.h.meson.in | 3 + meson.build | 15 + meson_options.txt | 2 + 13 files changed, 1085 insertions(+), 12 deletions(-) create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c diff --git a/configure.ac b/configure.ac index e4c2965d6..c8d46a075 100644 --- a/configure.ac +++ b/configure.ac @@ -590,6 +590,7 @@ AC_ARG_ENABLE(xvfb, AS_HELP_STRING([--enable-xvfb], [Build Xvfb server AC_ARG_ENABLE(xnest, AS_HELP_STRING([--enable-xnest], [Build Xnest server (default: auto)]), [XNEST=$enableval], [XNEST=auto]) AC_ARG_ENABLE(xquartz,AS_HELP_STRING([--enable-xquartz], [Build Xquartz server for OS-X (default: auto)]), [XQUARTZ=$enableval], [XQUARTZ=auto]) AC_ARG_ENABLE(xwayland, AS_HELP_STRING([--enable-xwayland], [Build Xwayland server (default: auto)]), [XWAYLAND=$enableval], [XWAYLAND=auto]) +AC_ARG_ENABLE(xwayland-eglstream, AS_HELP_STRING([--enable-xwayland-eglstream], [Build Xwayland eglstream support (default: no)]), [XWAYLAND_EGLSTREAM=$enableval], [XWAYLAND_EGLSTREAM=no]) AC_ARG_ENABLE(standalone-xpbproxy, AS_HELP_STRING([--enable-standalone-xpbproxy], [Build a standalone xpbproxy (in addition to the one integrated into Xquartz as a separate thread) (default: no)]), [STANDALONE_XPBPROXY=$enableval], [STANDALONE_XPBPROXY=no]) AC_ARG_ENABLE(xwin, AS_HELP_STRING([--enable-xwin], [Build XWin server (default: auto)]), [XWIN=$enableval], [XWIN=auto]) AC_ARG_ENABLE(glamor, AS_HELP_STRING([--enable-glamor], [Build glamor dix module (default: auto)]), [GLAMOR=$enableval], [GLAMOR=auto]) @@ -2380,6 +2381,29 @@ if test "x$XWAYLAND" = xyes; then [Build xwayland with glamor support]) fi + PKG_CHECK_MODULES(WAYLAND_EGLSTREAM, [wayland-eglstream-protocols >= 1.0.2], [have_wl_eglstream=yes], [have_wl_eglstream=no]) + + if test "x$XWAYLAND_EGLSTREAM" = xauto; then + if test "x$have_wl_eglstream" = xyes && test "x$GLAMOR" = xyes; then + XWAYLAND_EGLSTREAM=yes + fi + fi + + if test "x$XWAYLAND_EGLSTREAM" = xyes; then + if test "x$GLAMOR" != xyes; then + AC_MSG_ERROR([Xwayland eglstream support explicitly requested, but required modules not found.]) + fi + + if test "x$have_wl_eglstream" = xno; then + AC_MSG_ERROR([Xwayland eglstream support requires wayland-eglstream-protocols >= 1.0.2]) + fi + + AC_SUBST(WAYLAND_EGLSTREAM_DATADIR, `$PKG_CONFIG --variable=pkgdatadir wayland-eglstream-protocols`) + AC_DEFINE(XWL_HAS_EGLSTREAM, 1, + [Build xwayland with eglstream support]) + fi + AM_CONDITIONAL(XWAYLAND_EGLSTREAM, [test "x$XWAYLAND_EGLSTREAM" = "xyes"]) + XWAYLAND_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB $RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB $MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB $XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB" XWAYLAND_SYS_LIBS="$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS" AC_SUBST([XWAYLAND_LIBS]) diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am index d9e9fe8b6..d39fa7547 100644 --- a/hw/xwayland/Makefile.am +++ b/hw/xwayland/Makefile.am @@ -40,6 +40,11 @@ Xwayland_SOURCES += \ xwayland-glamor-xv.c endif +if XWAYLAND_EGLSTREAM +Xwayland_SOURCES +=\ + xwayland-glamor-eglstream.c +endif + glamor_built_sources = \ drm-client-protocol.h \ drm-protocol.c @@ -64,13 +69,19 @@ Xwayland_built_sources += \ xdg-output-unstable-v1-protocol.c \ xdg-output-unstable-v1-client-protocol.h +if XWAYLAND_EGLSTREAM +Xwayland_built_sources += \ + wayland-eglstream-client-protocol.h \ + wayland-eglstream-protocol.c\ + wayland-eglstream-controller-client-protocol.h
[RFC 2/3] xwayland: Add xwayland-config.h
Just a small autogenerated header that will soon contain more then just
one macro.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
configure.ac | 7 +++
hw/xwayland/xwayland.c | 10 ++
hw/xwayland/xwayland.h | 2 +-
include/meson.build| 7 +++
include/xwayland-config.h.in | 10 ++
include/xwayland-config.h.meson.in | 8
6 files changed, 39 insertions(+), 5 deletions(-)
create mode 100644 include/xwayland-config.h.in
create mode 100644 include/xwayland-config.h.meson.in
diff --git a/configure.ac b/configure.ac
index 98b8ea2ed..e4c2965d6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,6 +67,8 @@ dnl xkb-config.h covers XKB for the Xorg and Xnest DDXs.
AC_CONFIG_HEADERS(include/xkb-config.h)
dnl xwin-config.h covers the XWin DDX.
AC_CONFIG_HEADERS(include/xwin-config.h)
+dnl xwayland-config.h covers Xwayland.
+AC_CONFIG_HEADERS(include/xwayland-config.h)
dnl version-config.h covers the version numbers so they can be bumped without
dnl forcing an entire recompile.x
AC_CONFIG_HEADERS(include/version-config.h)
@@ -2373,6 +2375,11 @@ if test "x$XWAYLAND" = xyes; then
AC_MSG_ERROR([Xwayland build explicitly requested, but required
modules not found.])
fi
+ if test "x$GLAMOR" = xyes && test "x$GBM" = xyes; then
+ AC_DEFINE(XWL_HAS_GLAMOR, 1,
+ [Build xwayland with glamor support])
+ fi
+
XWAYLAND_LIBS="$FB_LIB $FIXES_LIB $MI_LIB $XEXT_LIB $DBE_LIB
$RECORD_LIB $GLX_LIBS $RANDR_LIB $RENDER_LIB $DAMAGE_LIB $DRI3_LIB $PRESENT_LIB
$MIEXT_SYNC_LIB $MIEXT_DAMAGE_LIB $MIEXT_SHADOW_LIB $XI_LIB $XKB_LIB
$XKB_STUB_LIB $COMPOSITE_LIB $MAIN_LIB $DIX_LIB $OS_LIB"
XWAYLAND_SYS_LIBS="$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS"
AC_SUBST([XWAYLAND_LIBS])
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 979b72918..f4a9a0615 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -647,7 +647,7 @@ xwl_window_post_damage(struct xwl_window *xwl_window)
region = DamageRegion(xwl_window->damage);
pixmap = (*xwl_screen->screen->GetWindowPixmap) (xwl_window->window);
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor)
buffer = xwl_glamor_pixmap_get_wl_buffer(pixmap);
else
@@ -725,7 +725,7 @@ registry_global(void *data, struct wl_registry *registry,
uint32_t id,
wl_registry_bind(registry, id, _output_manager_v1_interface,
1);
xwl_screen_init_xdg_output(xwl_screen);
}
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
else if (xwl_screen->glamor) {
xwl_glamor_init_wl_registry(xwl_screen, registry, id, interface,
version);
@@ -909,7 +909,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
dixSetPrivate(>devPrivates, _screen_private_key, xwl_screen);
xwl_screen->screen = pScreen;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
xwl_screen->glamor = 1;
#endif
@@ -937,12 +937,14 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
}
}
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor) {
if (!xwl_glamor_init_gbm(xwl_screen)) {
ErrorF("xwayland glamor: failed to setup GBM backend, falling back
to sw accel\n");
xwl_screen->glamor = 0;
}
}
+#endif
/* In rootless mode, we don't have any screen storage, and the only
* rendering should be to redirected mode. */
@@ -1026,7 +1028,7 @@ xwl_screen_init(ScreenPtr pScreen, int argc, char **argv)
if (!xwl_screen_init_cursor(xwl_screen))
return FALSE;
-#ifdef GLAMOR_HAS_GBM
+#ifdef XWL_HAS_GLAMOR
if (xwl_screen->glamor && !xwl_glamor_init(xwl_screen)) {
ErrorF("Failed to initialize glamor, falling back to sw\n");
xwl_screen->glamor = 0;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 88e9ec832..7961cc6f1 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -26,7 +26,7 @@
#ifndef XWAYLAND_H
#define XWAYLAND_H
-#include
+#include
#include
#include
diff --git a/include/meson.build b/include/meson.build
index 00ec0573d..a5701fc53 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -293,6 +293,13 @@ configure_file(output : 'xwin-config.h',
input : 'xwin-config.h.meson.in',
configuration : xwin_data)
+xwayland_data = configuration_data()
+xwayland_data.set('XWL_HAS_GLAMOR', build_glamor and gbm_dep.found())
+
+configure_file(output : 'xwayland-config.h',
+ input : 'xwayland-config.h.meson.in',
+ configuration : xwayland_data)
+
if build_xorg
install_data(
[
diff --git a/include/xwayland-config.h.in b/include/xwayland-config.h.in
new fil
[RFC 1/3] xwayland: Decouple GBM from glamor
This takes all of the gbm related code in wayland-glamor.c and moves it
into it's own EGL backend for Xwayland, xwayland-glamor-gbm.c.
Additionally, we add the egl_backend struct into xwl_screen in order to
provide hooks for alternative EGL backends such as nvidia's EGLStreams.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xwayland/Makefile.am | 3 +-
hw/xwayland/meson.build | 1 +
hw/xwayland/xwayland-glamor-gbm.c | 628 ++
hw/xwayland/xwayland-glamor.c | 500 +-
hw/xwayland/xwayland.c| 13 +-
hw/xwayland/xwayland.h| 54 +++-
6 files changed, 701 insertions(+), 498 deletions(-)
create mode 100644 hw/xwayland/xwayland-glamor-gbm.c
diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
index 7204591e3..d9e9fe8b6 100644
--- a/hw/xwayland/Makefile.am
+++ b/hw/xwayland/Makefile.am
@@ -33,7 +33,8 @@ Xwayland_built_sources =
if GLAMOR_EGL
Xwayland_SOURCES +=\
- xwayland-glamor.c
+ xwayland-glamor.c \
+ xwayland-glamor-gbm.c
if XV
Xwayland_SOURCES +=\
xwayland-glamor-xv.c
diff --git a/hw/xwayland/meson.build b/hw/xwayland/meson.build
index 24203c63e..d219e2f44 100644
--- a/hw/xwayland/meson.build
+++ b/hw/xwayland/meson.build
@@ -43,6 +43,7 @@ srcs += code.process(xdg_output_xml)
xwayland_glamor = []
if gbm_dep.found()
srcs += 'xwayland-glamor.c'
+srcs += 'xwayland-glamor-gbm.c'
if build_xv
srcs += 'xwayland-glamor-xv.c'
endif
diff --git a/hw/xwayland/xwayland-glamor-gbm.c
b/hw/xwayland/xwayland-glamor-gbm.c
new file mode 100644
index 0..b93079900
--- /dev/null
+++ b/hw/xwayland/xwayland-glamor-gbm.c
@@ -0,0 +1,628 @@
+/*
+ * Copyright © 2011-2014 Intel Corporation
+ * Copyright © 2017 Red Hat Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy,
+ * modify, merge, publish, distribute, sublicense, and/or sell copies
+ * of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including
+ * the next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ *Lyude Paul <ly...@redhat.com>
+ *
+ */
+
+#include "xwayland.h"
+
+#include
+#include
+#include
+
+#define MESA_EGL_NO_X11_HEADERS
+#include
+#include
+
+#include
+#include
+#include
+#include "drm-client-protocol.h"
+
+struct xwl_gbm_private {
+struct gbm_device *gbm;
+struct wl_drm *drm;
+char *device_name;
+int drm_fd;
+int fd_render_node;
+Bool drm_authenticated;
+uint32_t capabilities;
+};
+
+struct xwl_pixmap {
+struct wl_buffer *buffer;
+EGLImage image;
+unsigned int texture;
+struct gbm_bo *bo;
+};
+
+static DevPrivateKeyRec xwl_gbm_private_key;
+static DevPrivateKeyRec xwl_auth_state_private_key;
+
+static inline struct xwl_gbm_private *
+xwl_gbm_get(struct xwl_screen *xwl_screen)
+{
+return dixLookupPrivate(_screen->screen->devPrivates,
+_gbm_private_key);
+}
+
+static uint32_t
+gbm_format_for_depth(int depth)
+{
+switch (depth) {
+case 16:
+return GBM_FORMAT_RGB565;
+case 24:
+return GBM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return GBM_FORMAT_ARGB;
+}
+}
+
+static uint32_t
+drm_format_for_depth(int depth)
+{
+switch (depth) {
+case 15:
+return WL_DRM_FORMAT_XRGB1555;
+case 16:
+return WL_DRM_FORMAT_RGB565;
+case 24:
+return WL_DRM_FORMAT_XRGB;
+default:
+ErrorF("unexpected depth: %d\n", depth);
+case 32:
+return WL_DRM_FORMAT_ARGB;
+}
+}
+
+static char
+is_fd_render_node(int fd)
+{
+struct stat render;
+
+if (fstat(fd, ))
+return 0;
+if (!S_ISCHR(render.st_mode))
+return 0;
+if (render.st_rdev & 0x80)
+return 1;
+
+return 0;
+}
+
+static PixmapPtr
+xwl_glamor_gbm_create_pixmap_for_bo(ScreenPtr screen, st
[RFC 0/3] xwayland: Add support for eglstreams
The day has finally come. "Yay". As many of you are aware, nvidia currently only has makeshift support for Wayland using the EGLStream protocol. Unfortunately, nvidia makes up a huge amount of consumer machine's GPUs so until they get proper wayland support, we have to support this in X. This patchset isn't terribly useful from the perspective of a user: it doesn't provide hardware acceleration to X apps yet, as that will require glxvnd support. It does however, at least draw X pixmaps onto the screen using the GPU. It's a start. We also add some EGLDevice helpers with this, for the day when mesa grows the ability to support extensions. Lyude Paul (3): xwayland: Decouple GBM from glamor xwayland: Add xwayland-config.h xwayland: Add glamor egl_backend for EGLStreams configure.ac| 31 ++ hw/xwayland/Makefile.am | 26 +- hw/xwayland/meson.build | 18 +- hw/xwayland/xwayland-glamor-eglstream.c | 813 hw/xwayland/xwayland-glamor-gbm.c | 624 hw/xwayland/xwayland-glamor.c | 577 +-- hw/xwayland/xwayland.c | 57 ++- hw/xwayland/xwayland.h | 95 +++- include/meson.build | 10 +- include/xwayland-config.h.in| 13 + include/xwayland-config.h.meson.in | 11 + meson.build | 15 + meson_options.txt | 2 + 13 files changed, 1801 insertions(+), 491 deletions(-) create mode 100644 hw/xwayland/xwayland-glamor-eglstream.c create mode 100644 hw/xwayland/xwayland-glamor-gbm.c create mode 100644 include/xwayland-config.h.in create mode 100644 include/xwayland-config.h.meson.in -- 2.14.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver v2] xwayland: Don't process cursor warping without an xwl_seat
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x774f0e79 in wl_proxy_marshal () from
target:/lib64/libwayland-client.so.0
#1 0x00413172 in zwp_confined_pointer_v1_destroy
(zwp_confined_pointer_v1=0x7)
at
hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x00418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x00418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x00410d97 in xwl_cursor_confined_to (device=0xa5a000,
screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70,
generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x00502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x0041a83c in update_screen_size (xwl_output=0x8e7670, width=3840,
height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x0041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x0041aaeb in xdg_output_handle_done (data=0x8e7670,
xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x750e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x750e968f in ffi_call (cif=, fn=,
rvalue=,
avalue=) at ../src/x86/ffi64.c:525
#13 0x774f3d8b in wl_closure_invoke () from
target:/lib64/libwayland-client.so.0
#14 0x774f0928 in dispatch_event.isra () from
target:/lib64/libwayland-client.so.0
#15 0x774f1be4 in wl_display_dispatch_queue_pending () from
target:/lib64/libwayland-client.so.0
#16 0x774f200b in wl_display_roundtrip_queue () from
target:/lib64/libwayland-client.so.0
#17 0x00418cad in InitInput (argc=12, argv=0x7fffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x004a20e3 in dix_main (argc=12, argv=0x7fffd9c8,
envp=0x7fffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x00420cb2 in main (argc=12, argv=0x7fffd9c8,
envp=0x7fffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). While not against protocol, mutter ends
up sending xdg_output before wl_seat. xwl_screen_get_default_seat()
makes the naïve assumption that we always have a valid seat, we end up
returning a pointer to the empty list itself instead of an actual seat
and causing ourselves to segfault.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xwayland/xwayland.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 19aa14a47..9b1d85674 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -265,6 +265,9 @@ xwl_close_screen(ScreenPtr screen)
static struct xwl_seat *
xwl_screen_get_default_seat(struct xwl_screen *xwl_screen)
{
+if (xorg_list_is_empty(_screen->seat_list))
+return NULL;
+
return container_of(xwl_screen->seat_list.prev,
struct xwl_seat,
link);
@@ -324,6 +327,10 @@ xwl_cursor_confined_to(DeviceIntPtr device,
if (!xwl_seat)
xwl_seat = xwl_screen_get_default_seat(xwl_screen);
+/* xwl_seat hasn't been setup yet, don't do anything just yet */
+if (!xwl_seat)
+return;
+
if (window == screen->root) {
xwl_seat_unconfine_pointer(xwl_seat);
return;
--
2.14.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] xwayland: Don't process cursor warping without an xwl_seat
Unfortunately, on my machine Xwayland immediately crashes when I try to
start it. gdb backtrace:
#0 0x774f0e79 in wl_proxy_marshal () from
target:/lib64/libwayland-client.so.0
#1 0x00413172 in zwp_confined_pointer_v1_destroy
(zwp_confined_pointer_v1=0x7)
at
hw/xwayland/Xwayland@exe/pointer-constraints-unstable-v1-client-protocol.h:612
#2 0x00418bc0 in xwl_seat_destroy_confined_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2839
#3 0x00418c09 in xwl_seat_unconfine_pointer (xwl_seat=0x8ba2a0)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2849
#4 0x00410d97 in xwl_cursor_confined_to (device=0xa5a000,
screen=0x8b9d80, window=0x9bdb70)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland.c:328
#5 0x004a8571 in ConfineCursorToWindow (pDev=0xa5a000, pWin=0x9bdb70,
generateEvents=1,
confineToScreen=0) at /home/lyudess/Projects/xserver/dix/events.c:900
#6 0x004a94b7 in ScreenRestructured (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/dix/events.c:1387
#7 0x00502386 in RRScreenSizeNotify (pScreen=0x8b9d80)
at /home/lyudess/Projects/xserver/randr/rrscreen.c:160
#8 0x0041a83c in update_screen_size (xwl_output=0x8e7670, width=3840,
height=2160)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:203
#9 0x0041a9f0 in apply_output_change (xwl_output=0x8e7670)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:252
#10 0x0041aaeb in xdg_output_handle_done (data=0x8e7670,
xdg_output=0x8e7580)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-output.c:307
#11 0x750e9d1e in ffi_call_unix64 () at ../src/x86/unix64.S:76
#12 0x750e968f in ffi_call (cif=, fn=,
rvalue=,
avalue=) at ../src/x86/ffi64.c:525
#13 0x774f3d8b in wl_closure_invoke () from
target:/lib64/libwayland-client.so.0
#14 0x774f0928 in dispatch_event.isra () from
target:/lib64/libwayland-client.so.0
#15 0x774f1be4 in wl_display_dispatch_queue_pending () from
target:/lib64/libwayland-client.so.0
#16 0x774f200b in wl_display_roundtrip_queue () from
target:/lib64/libwayland-client.so.0
#17 0x00418cad in InitInput (argc=12, argv=0x7fffd9c8)
at /home/lyudess/Projects/xserver/hw/xwayland/xwayland-input.c:2867
#18 0x004a20e3 in dix_main (argc=12, argv=0x7fffd9c8,
envp=0x7fffda30)
at /home/lyudess/Projects/xserver/dix/main.c:250
#19 0x00420cb2 in main (argc=12, argv=0x7fffd9c8,
envp=0x7fffda30)
at /home/lyudess/Projects/xserver/dix/stubmain.c:34
This appears to be the result of xwl_cursor_confined_to() and
xwl_screen_get_default_seat(). xwl_cursor_confined_to() can be called
very on during the Xwayland init sequence, well before any seat has
actually been created for the server. However, this function doesn't
make an attempt to actually check for whether or not there's currently
a seat available, and just eagerly assumes that
xwl_screen_get_default_seat() will always return a valid seat.
Unfortunately, before an xwl_seat is actually initialized the xorg_list
will be in a fresh state with no members in it, e.g. list->prev ==
list->next == Since xwl_screen_get_default_seat() doesn't actually check
whether or not the seat list is empty, this causes us to end up
returning a pointer to instead of an actual xwl_seat struct, which
subsequently causes us to crash.
So, actually return NULL in xwl_screen_get_default_seat() if the seat
list is empty, and skip any pointer confinement processing in
xwl_cursor_confined_to() when we don't have a seat setup yet.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
Just a quick note!!! I haven't actually tested at all whether or not
this breaks cursor confinement, if you have any demo applications I use
to easily do this please let me know. I have at least, tested that this
lets me start Xwayland again :).
hw/xwayland/xwayland.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 19aa14a47..9b1d85674 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -265,6 +265,9 @@ xwl_close_screen(ScreenPtr screen)
static struct xwl_seat *
xwl_screen_get_default_seat(struct xwl_screen *xwl_screen)
{
+if (xorg_list_is_empty(_screen->seat_list))
+return NULL;
+
return container_of(xwl_screen->seat_list.prev,
struct xwl_seat,
link);
@@ -324,6 +327,10 @@ xwl_cursor_confined_to(DeviceIntPtr device,
if (!xwl_seat)
xwl_seat = xwl_screen_get_default_seat(xwl_screen);
+/* xwl_seat hasn't been setup yet, don't do anything just yet */
+if (!xwl_seat)
+return;
+
if (window == screen->root) {
xwl_seat_unconfine_pointer(xwl_seat);
[PATCH xserver 4/4] meson: Don't forget to define DEBUG!
Changes since v2:
- Don't enable by default for debugoptimized builds
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
include/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 5d746eb70..ce933ca43 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -196,6 +196,9 @@ conf_data.set('XvMCExtension', build_xv)
conf_data.set('HAVE_SHA1_IN_LIBNETTLE', '1') # XXX
+enable_debugging = get_option('buildtype') == 'debug'
+conf_data.set('DEBUG', enable_debugging)
+
conf_data.set_quoted('XVENDORNAME', get_option('vendor_name'))
conf_data.set_quoted('XVENDORNAMESHORT', get_option('vendor_name_short'))
conf_data.set_quoted('__VENDORDWEBSUPPORT__', get_option('vendor_web'))
@@ -282,7 +285,6 @@ xwin_data.set('HAS_WINSOCK', host_machine.system() ==
'windows', description: 'U
xwin_data.set('HAS_DEVWINDOWS', host_machine.system() == 'cygwin',
description: 'Has /dev/windows for signaling new win32 messages')
xwin_data.set('RELOCATE_PROJECTROOT', host_machine.system() == 'windows',
description: 'Make paths relative to the xserver installation location')
# XXX: these three are all the same as DEBUG so we should just change to that
-enable_debugging = (get_option('buildtype') == 'debug') or
(get_option('buildtype') == 'debugoptimized')
xwin_data.set10('CYGDEBUG', enable_debugging)
xwin_data.set10('CYGWINDOWING_DEBUG',enable_debugging)
xwin_data.set10('CYGMULTIWINDOW_DEBUG', enable_debugging)
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 2/4] x86emu: Fix type conversion warnings on x86_64 with DEBUG
Warnings come from the fact that PRIx32 is not used for printing 32 bit
values instead of "%lx", and "%lx" evaluates to a 64 bit long on 64 bit
systems while PRIx32 always evaluates to the right type for the
respective arch.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xfree86/x86emu/sys.c | 12 ++--
hw/xfree86/x86emu/x86emu/types.h | 1 +
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/hw/xfree86/x86emu/sys.c b/hw/xfree86/x86emu/sys.c
index 5eba35856..ccce540e7 100644
--- a/hw/xfree86/x86emu/sys.c
+++ b/hw/xfree86/x86emu/sys.c
@@ -191,7 +191,7 @@ rdb(u32 addr)
u8 val;
if (addr > M.mem_size - 1) {
-DB(printk("mem_read: address %#lx out of range!\n", addr);
+DB(printk("mem_read: address %#" PRIx32 " out of range!\n", addr);
)
HALT_SYS();
}
@@ -217,7 +217,7 @@ rdw(u32 addr)
u16 val = 0;
if (addr > M.mem_size - 2) {
-DB(printk("mem_read: address %#lx out of range!\n", addr);
+DB(printk("mem_read: address %#" PRIx32 " out of range!\n", addr);
)
HALT_SYS();
}
@@ -249,7 +249,7 @@ rdl(u32 addr)
u32 val = 0;
if (addr > M.mem_size - 4) {
-DB(printk("mem_read: address %#lx out of range!\n", addr);
+DB(printk("mem_read: address %#" PRIx32 " out of range!\n", addr);
)
HALT_SYS();
}
@@ -282,7 +282,7 @@ wrb(u32 addr, u8 val)
DB(if (DEBUG_MEM_TRACE())
printk("%#08x 1 <- %#x\n", addr, val);)
if (addr > M.mem_size - 1) {
-DB(printk("mem_write: address %#lx out of range!\n", addr);
+DB(printk("mem_write: address %#" PRIx32 " out of range!\n",addr);
)
HALT_SYS();
}
@@ -303,7 +303,7 @@ wrw(u32 addr, u16 val)
DB(if (DEBUG_MEM_TRACE())
printk("%#08x 2 <- %#x\n", addr, val);)
if (addr > M.mem_size - 2) {
-DB(printk("mem_write: address %#lx out of range!\n", addr);
+DB(printk("mem_write: address %#" PRIx32 " out of range!\n",addr);
)
HALT_SYS();
}
@@ -331,7 +331,7 @@ wrl(u32 addr, u32 val)
DB(if (DEBUG_MEM_TRACE())
printk("%#08x 4 <- %#x\n", addr, val);)
if (addr > M.mem_size - 4) {
-DB(printk("mem_write: address %#lx out of range!\n", addr);
+DB(printk("mem_write: address %#" PRIx32 " out of range!\n",addr);
)
HALT_SYS();
}
diff --git a/hw/xfree86/x86emu/x86emu/types.h b/hw/xfree86/x86emu/x86emu/types.h
index 5a6ef01f8..0559bc089 100644
--- a/hw/xfree86/x86emu/x86emu/types.h
+++ b/hw/xfree86/x86emu/x86emu/types.h
@@ -61,6 +61,7 @@
/*-- Macros and type definitions --*/
#include
+#include
typedef uint8_t u8;
typedef uint16_t u16;
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 3/4] meson: Silence -Wformat-nonliteral for x86emu
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xfree86/int10/meson.build | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/xfree86/int10/meson.build b/hw/xfree86/int10/meson.build
index 3bcf99ab4..b1ead9c4c 100644
--- a/hw/xfree86/int10/meson.build
+++ b/hw/xfree86/int10/meson.build
@@ -25,6 +25,12 @@ if int10 == 'x86emu'
]
int10_c_args += '-D_X86EMU'
int10_c_args += '-DNO_SYS_HEADERS'
+
+# Silence some useless warnings from x86emu
+if cc.has_argument('-Wno-format-nonliteral')
+int10_c_args += '-Wno-format-nonliteral'
+endif
+
int10_link += xorg_x86emu
endif
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 0/4] meson: Fix DEBUG definition
At the moment, meson makes the mistake of never defining the DEBUG macro, regardless of the current build type. Unfortunately, just enabling that definition by default for debug builds brought up a good number of compiler warnings and errors from other files that were being silenced due to that. This series makes it so meson defines DEBUG when the buildtype is debug, while additionally also fixing all of the compiler warnings/errors this causes in the default configuration. Lyude Paul (4): fbdevhw: Fix inconsistent #if DEBUG usage x86emu: Fix type conversion warnings on x86_64 with DEBUG meson: Silence -Wformat-nonliteral for x86emu meson: Don't forget to define DEBUG! hw/xfree86/fbdevhw/fbdevhw.c | 6 +++--- hw/xfree86/int10/meson.build | 6 ++ hw/xfree86/x86emu/sys.c | 12 ++-- hw/xfree86/x86emu/x86emu/types.h | 1 + include/meson.build | 4 +++- 5 files changed, 19 insertions(+), 10 deletions(-) -- 2.13.6 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver 1/4] fbdevhw: Fix inconsistent #if DEBUG usage
fbdevhw is the only file in X's source that actually uses #if DEBUG to
check for debugging instead of #ifdef DEBUG. This is contrary to
everything else that checks the DEBUG macro in the source, so let's make
it consistent and in turn, make our meson files a little simpler.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
hw/xfree86/fbdevhw/fbdevhw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
index b50ae5ed2..0bd77df87 100644
--- a/hw/xfree86/fbdevhw/fbdevhw.c
+++ b/hw/xfree86/fbdevhw/fbdevhw.c
@@ -120,7 +120,7 @@ fbdevHWGetFD(ScrnInfoPtr pScrn)
/* */
/* some helpers for printing debug informations */
-#if DEBUG
+#ifdef DEBUG
static void
print_fbdev_mode(const char *txt, struct fb_var_screeninfo *var)
{
@@ -466,7 +466,7 @@ fbdevHWSetMode(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool
check)
xfree2fbdev_fblayout(pScrn, _var);
xfree2fbdev_timing(mode, _var);
-#if DEBUG
+#ifdef DEBUG
print_xfree_mode("init", mode);
print_fbdev_mode("init", _var);
#endif
@@ -486,7 +486,7 @@ fbdevHWSetMode(ScrnInfoPtr pScrn, DisplayModePtr mode, Bool
check)
if (!check)
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"FBIOPUT_VSCREENINFO succeeded but modified " "mode\n");
-#if DEBUG
+#ifdef DEBUG
print_fbdev_mode("returned", _var);
#endif
return FALSE;
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] meson: Don't forget to define DEBUG!
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
include/meson.build | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 90f8de3cb..8894885c6 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -196,6 +196,9 @@ conf_data.set('XvMCExtension', build_xv)
conf_data.set('HAVE_SHA1_IN_LIBNETTLE', '1') # XXX
+enable_debugging = (get_option('buildtype') == 'debug') or
(get_option('buildtype') == 'debugoptimized')
+conf_data.set('DEBUG', enable_debugging)
+
conf_data.set_quoted('XVENDORNAME', get_option('vendor_name'))
conf_data.set_quoted('XVENDORNAMESHORT', get_option('vendor_name_short'))
conf_data.set_quoted('__VENDORDWEBSUPPORT__', get_option('vendor_web'))
@@ -282,7 +285,6 @@ xwin_data.set('HAS_WINSOCK', host_machine.system() ==
'windows', description: 'U
xwin_data.set('HAS_DEVWINDOWS', host_machine.system() == 'cygwin',
description: 'Has /dev/windows for signaling new win32 messages')
xwin_data.set('RELOCATE_PROJECTROOT', host_machine.system() == 'windows',
description: 'Make paths relative to the xserver installation location')
# XXX: these three are all the same as DEBUG so we should just change to that
-enable_debugging = (get_option('buildtype') == 'debug') or
(get_option('buildtype') == 'debugoptimized')
xwin_data.set10('CYGDEBUG', enable_debugging)
xwin_data.set10('CYGWINDOWING_DEBUG',enable_debugging)
xwin_data.set10('CYGMULTIWINDOW_DEBUG', enable_debugging)
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] meson: Add xkb_bin_dir option
Now that we can actually configure all of the directories xkb uses for
finding things, we can (finally, but only with meson) finally make it so
that with the correct meson configuration the Xserver will "just work"
without any additional changes to the installation prefix after
building.
For the people like me who have since scripted this part out of their
build process and forgotten about it, building and installing the X
server into a non-standard prefix has always required the following (or
something else that makes sure that X has a valid xkbcomp configuration)
commands be run right after doing the installation:
# start in root of prefix you installed X to
mkdir -pv share/X11/xkb/rules
ln -s /usr/share/X11/xkb/rules/evdev share/X11/xkb/rules/
rm -f bin/xkbcomp
ln -s /usr/bin/xkbcomp bin/
The one last piece of getting rid of this post-install junk is making
sure that we can control the directory that X uses for finding the
xkbcomp binary from meson so we can point it at the system provided
xkbcomp (/usr/bin/xkbcomp or similar). So, this patch adds a
configuration option for controlling this called xkb_bin_dir.
Signed-off-by: Lyude Paul <ly...@redhat.com>
---
include/meson.build | 2 +-
meson.build | 5 +
meson_options.txt | 1 +
3 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/include/meson.build b/include/meson.build
index 90f8de3cb..5d746eb70 100644
--- a/include/meson.build
+++ b/include/meson.build
@@ -219,7 +219,7 @@ configure_file(output : 'version-config.h',
xkb_data = configuration_data()
-xkb_data.set_quoted('XKB_BIN_DIRECTORY', join_paths(get_option('prefix'),
get_option('bindir')))
+xkb_data.set_quoted('XKB_BIN_DIRECTORY', xkb_bin_dir)
xkb_data.set_quoted('XKB_BASE_DIRECTORY', xkb_dir)
xkb_data.set_quoted('XKB_DFLT_RULES', get_option('xkb_default_rules'))
xkb_data.set_quoted('XKB_DFLT_MODEL', get_option('xkb_default_model'))
diff --git a/meson.build b/meson.build
index d71cfed5a..f9b21b36c 100644
--- a/meson.build
+++ b/meson.build
@@ -107,6 +107,11 @@ if xkb_output_dir == ''
xkb_output_dir = join_paths(get_option('prefix'), 'share/X11/xkb/compiled')
endif
+xkb_bin_dir = get_option('xkb_bin_dir')
+if xkb_bin_dir == ''
+xkb_bin_dir = join_paths(get_option('prefix'), get_option('bindir'))
+endif
+
hal_option = get_option('hal')
glamor_option = get_option('glamor')
diff --git a/meson_options.txt b/meson_options.txt
index b1ee6ccc5..1954ea7a0 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -29,6 +29,7 @@ option('ipv6', type: 'combo', choices: ['yes', 'no', 'auto'],
value: 'auto')
option('xkb_dir', type: 'string')
option('xkb_output_dir', type: 'string')
+option('xkb_bin_dir', type: 'string')
option('xkb_default_rules', type: 'string', value: 'evdev')
option('xkb_default_model', type: 'string', value: 'pc105')
option('xkb_default_layout', type: 'string', value: 'us')
--
2.13.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-video-nouveau 1.0.15
Ben Skeggs (1): fix null pointer deref when building against >=libdrm 2.4.78 Ilia Mirkin (1): Add Pascal family support, identical to Maxwell Lyude (1): Bump version to 1.0.15 Mariusz Bialonczyk (1): Do not register hotplug without RandR git tag: xf86-video-nouveau-1.0.15 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.15.tar.bz2 MD5: 717203cb87029cddcbccf7398f9ad8c3 xf86-video-nouveau-1.0.15.tar.bz2 SHA1: ed699a59ea509550f60019eef1e092ed0ccdea08 xf86-video-nouveau-1.0.15.tar.bz2 SHA256: aede10fd395610a328697adca3434fb14e9afbd79911d6c8545cfa2c0e541d4c xf86-video-nouveau-1.0.15.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.15.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.15.tar.gz MD5: 13035498cd5d66f47de075de8cc11ec9 xf86-video-nouveau-1.0.15.tar.gz SHA1: b7fcc51339a2058f2f82b3a806dfe9aa44ea6d2e xf86-video-nouveau-1.0.15.tar.gz SHA256: 3932af6878b000eac5a8992ce797f9c7a334f9b3257c5cf53f2bf177c1f942c2 xf86-video-nouveau-1.0.15.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.15.tar.gz.sig signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.x.org https://lists.x.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xf86-video-nouveau 1.0.14
Ilia Mirkin (7): exa: add GM10x acceleration support hwdefs: update nvc0_3d, add gm107_texture for new TIC format nvc0: make use of the new hwdefs for TEX_CB_INDEX nvc0: rename BEGIN_IMC0 to IMMED_NVC0 nvc0: refactor TIC uploads to allow different specifics per generation copy: add maxwell/pascal copy engine classes recognize and accelerate GM20x Lyude (2): Consider CRTCs disabled when DPMS is off Bump version to 1.0.14 git tag: xf86-video-nouveau-1.0.14 https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.14.tar.bz2 MD5: c57c89e1a3c9bc319d26f2e11c80e7fb xf86-video-nouveau-1.0.14.tar.bz2 SHA1: 6c5c46d6e0d8595b71e2a1df6879ab5d650f2097 xf86-video-nouveau-1.0.14.tar.bz2 SHA256: 4ddff99b3cc49f16cdcf99f6e1c5856b6f06589ec98376cedb5754100afe31c1 xf86-video-nouveau-1.0.14.tar.bz2 PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.14.tar.bz2.sig https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.14.tar.gz MD5: caf49bd019afc33474737ec05e315e57 xf86-video-nouveau-1.0.14.tar.gz SHA1: c0f174fe286a0ecb81e3f34c0df0e2f58889b8f7 xf86-video-nouveau-1.0.14.tar.gz SHA256: c0a944b5f1a2b8a3f2937c44d99edfbd5488350f3017d9c6da06dcc99d0ed6e0 xf86-video-nouveau-1.0.14.tar.gz PGP: https://xorg.freedesktop.org/archive/individual/driver/xf86-video-nouveau-1.0.14.tar.gz.sig signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.x.org https://lists.x.org/mailman/listinfo/xorg-announce
Re: xf86-video-amdgpu patch review moving to amd-gfx mailing list
I'm up for this. Better then having to send the same patches for both radeon and amdgpu to seperate mailing lists :) Cheers, Lyude On Wed, 2016-06-22 at 17:57 +0900, Michel Dänzer wrote: > This is a heads up that we'll be using the amd-...@lists.freedesktop.org > mailing list for xf86-video-amdgpu patch reviews from now on. > > Any opinions on whether we should do the same for xf86-video-ati > patches, or continue using this list for that? > > ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
