Change default Wayland branches to 'main'
Hi all, Going with a lot of other Git-based projects (and following the leads of e.g. GitHub and GitLab), freedesktop.org is planning to change the default branch name for its new projects to 'main' rather than 'master'. Mesa is already migrating, and they have helpfully prepared a small Python script which will retarget open MRs from 'master' to 'main'. I propose that we do this for all the wayland/* repositories, either this weekend or next; I'm happy to make the changes (rename 'master' to 'main' and retarget all open MRs). Does anyone have any opinions or suggestions? Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thu, 8 Apr 2021 12:20:46 +0100 Daniel Stone wrote: > Hi all, > Going with a lot of other Git-based projects (and following the leads of > e.g. GitHub and GitLab), freedesktop.org is planning to change the default > branch name for its new projects to 'main' rather than 'master'. > > Mesa is already migrating, and they have helpfully prepared a small Python > script which will retarget open MRs from 'master' to 'main'. > > I propose that we do this for all the wayland/* repositories, either this > weekend or next; I'm happy to make the changes (rename 'master' to 'main' > and retarget all open MRs). Does anyone have any opinions or suggestions? Hi, fine by me. Thanks, pq pgp1HWrnLvMaQ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thu, Apr 08, 2021 at 03:03:08PM +0300, Pekka Paalanen wrote: > On Thu, 8 Apr 2021 12:20:46 +0100 > Daniel Stone wrote: > > > Hi all, > > Going with a lot of other Git-based projects (and following the leads of > > e.g. GitHub and GitLab), freedesktop.org is planning to change the default > > branch name for its new projects to 'main' rather than 'master'. > > > > Mesa is already migrating, and they have helpfully prepared a small Python > > script which will retarget open MRs from 'master' to 'main'. > > > > I propose that we do this for all the wayland/* repositories, either this > > weekend or next; I'm happy to make the changes (rename 'master' to 'main' > > and retarget all open MRs). Does anyone have any opinions or suggestions? > > Hi, > > fine by me. No objections from me either. Jonas > > > Thanks, > pq > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thursday 2021-04-08 13:20, Daniel Stone wrote: > >I propose that we do this for all the wayland/* repositories, either this >weekend or next; I'm happy >to make the changes (rename 'master' to 'main' and retarget all open MRs). >Does anyone have any >opinions or suggestions? That could be offensive to some people. Some might even be offended by not being offended. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Wed, 07 Apr 2021, Hans Verkuil wrote: > On 07/04/2021 12:31, Jani Nikula wrote: >> On Wed, 07 Apr 2021, Hans Verkuil wrote: >>> It is the most complete EDID parser I know based on the various standards. >> >> Does it support pure DisplayID in addition to DisplayID blocks embedded >> to EDID extension blocks? I think we'll be needing that sometime in the >> near future. (We don't yet support that in the kernel either.) > > It doesn't, but that shouldn't be too hard to implement. > > Do you have examples of that? If I had some, then I could implement support > for it in edid-decode. Alas, I don't. We don't come across them naturally, because the kernel does not follow VESA E-DDC 1.3 to read 0x52 address to read the plain DisplayID. I guess it's also common to add DisplayID 2.0 data blocks in EDID extensions (and I see that edid-decode handles them), though this is not described in DisplayID 2.0 spec the way it is in older DisplayID specs. The differences aren't that big, really. Slightly different constraints on the block size when they're not embedded in EDID, as well as different mandatory blocks. Anyway, this is only tangentially related to the library. I just think we need to take DisplayID better into account also in the *users* of the library, as they shouldn't really even look at the EDID if the plain DisplayID is there, per E-DDC 1.3 section 3.1. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thu, 8 Apr 2021 at 14:02, Jan Engelhardt wrote: > On Thursday 2021-04-08 13:20, Daniel Stone wrote: > >I propose that we do this for all the wayland/* repositories, either this > weekend or next; I'm happy > >to make the changes (rename 'master' to 'main' and retarget all open > MRs). Does anyone have any > >opinions or suggestions? > > That could be offensive to some people. Some might even be offended by not > being offended. > I had hoped that 'serious suggestions' was implicit, but maybe not. Do you have any serious suggestions? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Thu, 08 Apr 2021 16:49:37 +0300 Jani Nikula wrote: > Anyway, this is only tangentially related to the library. I just think > we need to take DisplayID better into account also in the *users* of the > library, as they shouldn't really even look at the EDID if the plain > DisplayID is there, per E-DDC 1.3 section 3.1. That makes me wonder what the kernel DRM uAPI for getting a DisplayID block into userspace would be. A new read-only KMS connector property? Which means userspace (e.g. Weston) needs to know to read the new property. If it does that, then it already knows that it should favour DisplayID over EDID, and there is little the library could do to help with that. Unless you think the library should be making DRM ioctls, which doesn't sound good to me. Thanks, pq pgpL1dMZB2oa9.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thu, Apr 8, 2021 at 1:22 PM Daniel Stone wrote: > > Hi all, > Going with a lot of other Git-based projects (and following the leads of e.g. > GitHub and GitLab), freedesktop.org is planning to change the default branch > name for its new projects to 'main' rather than 'master'. > > Mesa is already migrating, and they have helpfully prepared a small Python > script which will retarget open MRs from 'master' to 'main'. > > I propose that we do this for all the wayland/* repositories, either this > weekend or next; I'm happy to make the changes (rename 'master' to 'main' and > retarget all open MRs). Does anyone have any opinions or suggestions? +1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Thu, 08 Apr 2021, Pekka Paalanen wrote: > On Thu, 08 Apr 2021 16:49:37 +0300 > Jani Nikula wrote: > >> Anyway, this is only tangentially related to the library. I just think >> we need to take DisplayID better into account also in the *users* of the >> library, as they shouldn't really even look at the EDID if the plain >> DisplayID is there, per E-DDC 1.3 section 3.1. > > That makes me wonder what the kernel DRM uAPI for getting a DisplayID > block into userspace would be. A new read-only KMS connector property? It's certainly a model everyone's used to working with. Is it worth coming up with something new when you anyway have to deal with the existing edid property for years to come? > Which means userspace (e.g. Weston) needs to know to read the new > property. If it does that, then it already knows that it should favour > DisplayID over EDID, and there is little the library could do to help > with that. Agreed. One of the problems for this uABI is that technically you're not supposed to read the EDID if the DisplayID is available. But the kernel needs to read both to expose both to userspace. I don't really see a way around that. The spec allows for leaving out EDID at 0x50 completely, which may eventually require updating kernel and userspace to be DisplayID aware. > Unless you think the library should be making DRM ioctls, which doesn't > sound good to me. Agreed, keep it simple. I'd say the library should probably stick to parsing an in-memory blob or fd passed to it, and focus on providing parsed information that's independent of the underlying data structure, whether it's DisplayID or EDID. Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula wrote: > Perhaps that should be the takeaway; try to minimize parsed data > where the consumer needs to know whether it originated from DisplayID or > EDID? So an EDID/DisplayID abstraction layer? It sounds like only an EDID and DisplayID expert could come up with a sane API for that. Also some metadata will only be available in one format and not the other. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Thu, 08 Apr 2021, Simon Ser wrote: > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula > wrote: > >> Perhaps that should be the takeaway; try to minimize parsed data >> where the consumer needs to know whether it originated from DisplayID or >> EDID? > > So an EDID/DisplayID abstraction layer? > > It sounds like only an EDID and DisplayID expert could come up with a > sane API for that. Also some metadata will only be available in one > format and not the other. Well, some of the data *already* comes from DisplayID extensions in the EDID. My point is, if you parse displayid and edid into different structures and APIs, what will the code bases using the library end up looking like? Not pretty? Implementing the same conditionals all over the place? Anyway. I feel like I'm derailing this a bit, and I really don't want that to happen. I think DisplayID is a consideration that should not be forgotten, but it's probably not the first priority here. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Call for an EDID parsing library
On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula wrote: > On Thu, 08 Apr 2021, Simon Ser cont...@emersion.fr wrote: > > > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula > > jani.nik...@linux.intel.com wrote: > > > > > Perhaps that should be the takeaway; try to minimize parsed data > > > where the consumer needs to know whether it originated from DisplayID or > > > EDID? > > > > So an EDID/DisplayID abstraction layer? > > > > It sounds like only an EDID and DisplayID expert could come up with a > > sane API for that. Also some metadata will only be available in one > > format and not the other. > > Well, some of the data already comes from DisplayID extensions in the > EDID. > > My point is, if you parse displayid and edid into different structures > and APIs, what will the code bases using the library end up looking > like? Not pretty? Implementing the same conditionals all over the place? > Anyway. I feel like I'm derailing this a bit, and I really don't want > that to happen. I think DisplayID is a consideration that should not be > forgotten, but it's probably not the first priority here. I agree with the goal. I'm just saying that it considerably increases the complexity of the task. If you're just doing an EDID library, you can just expose the EDID specific bits with a sane API. If you're designing an abstraction layer, you need to have a good look at both APIs, try to come up with common data structures that fit both, and be aware of the upcoming spec changes to not be stuck with a bad API. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Change default Wayland branches to 'main'
On Thursday 2021-04-08 16:04, Daniel Stone wrote: >On Thu, 8 Apr 2021 at 14:02, Jan Engelhardt wrote: >>On Thursday 2021-04-08 13:20, Daniel Stone wrote: >>>following the leads of e.g. GitHub and GitLab, [...] >>>I propose that we do this for all the wayland/* repositories, either this >>>weekend or next; I'm happy >>>to make the changes (rename 'master' to 'main' and retarget all open MRs). >>>Does anyone have any >>>opinions or suggestions? >> >>That could be offensive to some people. Some might even be offended by not >>being offended. > >I had hoped that 'serious suggestions' was implicit Part of the argument that Github/SFC made was inclusiveness, which is readily debunked, and when the hypocrisy is pointed out, one gets waved off as unserious. That's unserious in itself and shows quite a double standard. The serious suggestion is: try leaving it as is, save all parties the retargeting mess, and concentrate on continued software development. Not to mention that there isn't even a need to retarget, because you can simply have two branches with the same commit state. Work off MRs as time permits, and eventually all MRs to master are done, at which point the ref can be removed. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
