ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
andyrtr_ has joined #wayland
andyrtr has quit [Read error: Connection reset by peer]
andyrtr_ is now known as andyrtr
fmuellner has quit [Remote host closed the connection]
ahartmetz has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
Lightsword has quit [Server closed connection]
Lightsword has joined #wayland
ebassi has quit [Server closed connection]
ebassi has joined #wayland
cnsvc has quit [Server closed connection]
cnsvc has joined #wayland
ecocode__ has quit [Server closed connection]
ecocode__ has joined #wayland
panzeroceania_ has quit [Server closed connection]
<pq>
hardening, the shells are currently "weston plugins" and not "libweston plugins". It's a bit unfortunate, yes.
<hardening>
pq: yeah, I would have wrote a shell anyway, that just forces me to do it now and not have a quick PoC
erc has quit [Server closed connection]
erc has joined #wayland
<pq>
LaserEyess, don't forget the caveat with input vs. DRM leasing. If you lease an output, you cannot get the compositor to deliver input for anything on that output. You are going to need another window on some compositor controlled output to get input.
<pq>
swick, your feelings about edid-decode are the same that shashank has, and I have understood that shashank will go the new independent project route once he gets a chance.
<pq>
swick, personally I am scared about the amount of work needed to establish a new project from scratch.
<pq>
swick, I also think that a new project means that no-one who has worked on edid-decode will be there to help us. I would really want to involve the people around edid-decode, they have good wisdom.
<pq>
swick, for example: existing blocks may grow new fields, not just add whole new blocks, then EDID spec evolves.
<pq>
If more people are willing to put work into it than just shashank and my reviews, then I'd be more at ease starting a new project.
<pq>
I do think that a new project must create a tool identical to edid-decode, so that we can have CI check that the library/tool matches exactly what the read edid-decode prints.
<emersion>
yup
<pq>
*real edid-decode
<pq>
OTOH, *if* we can afford to start a new project from scratch, then we can have all the goodies we want from the very start: Meson, Gitlab, CI, contribution guidelines, etc.
<emersion>
hm i'm not a fan of shashank's lib
<pq>
not that lib, I don't think, but a new one
<pq>
I suggested to host it in gitlab.fd.o, for the same reasons and the same way as color-and-hdr
<emersion>
right, i was just looking at the existing code to see if that was a good start
<emersion>
but the header files are pretty messy
<emersion>
and noone of the goodies mentionned above are there
<emersion>
(not saying that's it's shitty code or anything -- writing a good EDID parser is a very difficult task)
<pq>
yup, I feel it needs a clean start, and put contribution guidelines + license as the very first thing.
<pq>
I'm trying to get shashank here, but he just timed out.
<emersion>
something i mentionned earlier too is that i wouldn't want to take the kernel approach and expose packed structs in our public API
<emersion>
(like shashank has done too)
<emersion>
reason being that it ties us to packed structs forever, and often times the fields themselves are not very meaningful and need post-processing
<pq>
FWIW, I've been thinking about how to design an ABI that allows exposing EDID blocks as structs for the low-level API while maintaining forward and likely also backward compatibility. It might be a bit much to explain in IRC though.
rgallaispou has joined #wayland
<emersion>
have you written your thoughts anywhere yet?
<pq>
yes, I don't want packed bit field structs either. I'm thinking the low-level struct should use friendly data types like enums and floats where appropriate.
<pq>
I haven't
novakane_ is now known as novakane
<ifreund>
yes, please no packed bit fields. They make using libraries from non-C languages horrible
<ifreund>
a simple uint32_t and some constants for bit masking is far friendlier and simpler
<pq>
even that is too low-level for me
<emersion>
yeah, high-level types and enums
<emersion>
pq, would you add getters with an opaque struct?
<pq>
depends on the field spec what is most appropriate, but even for the low-level API of ther lib, I'd go as high-level as possible within a block as long as it doesn't destroy information.
<emersion>
yup
shankaru has joined #wayland
<pq>
emersion, no, my idea is more like recording the "known" struct size as the first field of the struct, ensure a way to know which fields are actually populated, and use static inline functions to automatically copy between library runtime-version structs and library build-time-version structs so that all fields known at user build time are always valid memory, even if not populated.
<pq>
shankaru, hello, you made it! Did you see the irc log link I sent you?
<pq>
or did I confuse you with someone else?
<naveenk2>
pq: emersion: we were initially planning to come up with something like this:
<naveenk2>
Task 1: Create a library out of the edid-decode source: option: make library or make binary
<naveenk2>
Task 2: Draft high-level API as below
<naveenk2>
edid_parse_basic_display_info() => Break it into individual APIs like Serial no, Product, Manufacturer etc
<naveenk2>
edid_parse_supported_colorspaces()
<naveenk2>
edid_parse_hdr_info()
<naveenk2>
edid_parse_colorimetry_info()
<naveenk2>
Task 3: Create a test app to use high level wrapper APIs
<emersion>
pq: eh that sounds a bit complicated
<pq>
naveenk2, that plan sounds like you need complete all steps before you can do any kind of verification against edid-decode?
<emersion>
pq, i guess at first we don't necessarily need to have a stable ABI/API
<shankaru>
pq: Hi Pekka, didn't got the irc log. May be I missed it
<emersion>
so we could defer this problem to make things simpler
<emersion>
hi shankaru!
<shankaru>
emersion: Hi Simon
<pq>
emersion, IMO not really. As an API user, you get handed a struct you know is always fully accessible. If some fields are optional in some version, you need to check whether they exist anyway.
<emersion>
(btw, if anyone working on wayland wants an IRC bouncer to not miss messages let me know, we have a webapp + android app too)
<pq>
emersion, but yes, the alternative is myriads of getter functions. In that case you may not even need opaque structs for blocks.
<emersion>
pq, yeah if possible avaiding the myriad of getters would be best
<pq>
emersion, yeah, ABI can stabilize later, but changing the fundamental design of the ABI is a lot of work later.
<pq>
shankaru, then switch the log web page to today to see more.
<emersion>
pq, alternatively can't the user indicate the version when creating the edid parser?
<pq>
emersion, the library version? (Also EDID version comes into play.)
<emersion>
yeah lib version
<emersion>
which indicates the struct fields the user expects
<pq>
emersion, yes, it could, but then the library needs to maintain versioned struct definitions, right? As in lots of almost the same struct types, and then choose at runtime which one to return?
<emersion>
pq, if the structs are append-only there should only be one version (the latest)?
<pq>
right, but then again, EDID data may not contain all fields, so you also need an indication of which fields are populated
<emersion>
well basically my goal would be to avoid having one version per struct and replace it with just a single global per-parser version
<pq>
so I think it ends up pretty close to my idea
<emersion>
i think it woul;d be easier to discuss with code samples
<pq>
any struct needs to have a field with the struct's version (or size) so it can be verified at runtime, and then some static inline helper functions to make stuff typesafe.
<pq>
indeed
<naveenk2>
pq: right, but this saves us from writing everything from scratch or re-inventing things, also it will always align us with edid-decode maintainers and their experties
<emersion>
why does all struct need that?
<emersion>
i'm not liking the static inline helper
<pq>
emersion, how do you get type safety otherwise?
<pq>
naveenk2, I wonder if you missed the discussion between me, shashank and Hans Verkuil? That edid-decode does not actually save any of the information we want to return from the lib.
<emersion>
hm, let's take a step back. what's the exact problem we want to solve with this versionning?
<pq>
naveenk2, it prints the info and forgets it immediately from the very piece of code that parsed it.
<naveenk2>
hmm right I missed it
<emersion>
the usual scenario would be that a binary is compiled against an old libedid, and then libedid is updated to a newer version
<pq>
emersion, two problems: EDID data may or may not contain all fields; and library may be upgraded adding new fields (to structs) and new block types (structs) without rebuilding the users.
<emersion>
"EDID data may or may not contain all fields" can be fixed by having "null"/"invalid" values, or split the struct getters properly
<emersion>
depending on the situation
<pq>
naveenk2, that's the major reason to start from scratch, and copy stuff from edid-decode piece by piece when needed.
<emersion>
i don't think it's a good idea to try to fix these two problems together
<pq>
emersion, I do not see any difference between "EDID data did not contain this field" vs. "library did not parse this field". The end result is the same: no field. Only, in the latter case also the user would not have code to handle the field anyway.
<pq>
Both checks are needed in any case: does the field exist in the struct, and did the library populate it.
<emersion>
pq, "library did not parse this field" sounds like an old libedid with re-compiled users
<emersion>
against newer libedid
<pq>
no, it can also mean "EDID did not have the data"
<emersion>
you mentionned this right above as something different
<emersion>
> "EDID data did not contain this field" vs. "library did not parse this field"
<pq>
EDID data may or may not have the field; the library may or may not parse the field; the struct definition may or may not have the field.
<emersion>
an old libedid library will only miss newly appended fields
<emersion>
an EDID may miss fields in the middle of the struct
<emersion>
in any case, in my experience most of the optional stuff in EDID is caused by missing ext blocks for instance
<emersion>
there are a few cases of "no data" fields, but then we can just add a "no data" enum entry
<pq>
most, sure, but from what I understood from Hand, not all.
<pq>
*hans
<pq>
yes, that's required in one way or another
<pq>
I think my idea would achieve also backward compatibility in the ABI, not just forward compatibility. Is that worth it? Maybe not.
<pq>
anyway, all this would be much easier to discuss in a gitlab MR with some code, which is why I haven't tried to bring this up before
<emersion>
indeed
<pq>
For me it was a surprise that existing EDID blocks *can* grow new fields. If we hadn't talked with Hans, I would not have known. This is the kind of knowledge I was hoping to get from edid-decode community.
flacks has quit [Quit: Quitter]
<pq>
I didn't even know to ask about it, it just came up as a side comment from Hans.
<emersion>
well, that's what the EDID version is for yeah
<emersion>
iirc fields can also be re-purposed?
<pq>
is it? not feature bits inside a block?
flacks has joined #wayland
<emersion>
i don't really remember, but i think i came across a re-purposed field at some point
<pq>
If fields can be re-purposed, that is an extremely good reason to *not* expose an EDID block as a bit-by-bit struct type in API.
<emersion>
> Section 3.6.4 Feature Support Byte - Added Supported Color Encoding Formats; Replaced Preferred Timing Mode (PTM) Bit with PTM includes or does not include Native Pixel Format/Preferred Refresh Rate of the display device and replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
<emersion>
example or re-purposed field in a later EDID revision
<emersion>
of*
<emersion>
pq, some fields are marked as "reserved" and used in later revisions
<emersion>
for more funky EDID stuff have a look at #dri-devel :P
ahartmetz has quit [Remote host closed the connection]
ahartmetz has joined #wayland
<shankaru>
pq: yeah as emerison said, reserved and extensible blocks are the way EDID remains backward compatible
<shankaru>
For the parser library, we can define the structure with relevant info per entity like colorimtery, hdr etc
<shankaru>
we can have some resrved fields to be future proof
<shankaru>
clients can call the library helpers with defined structure, library parses the EDID, fills the structure and returns the same to client
<shankaru>
caching this info should be taken care by client itself
<shankaru>
also library helpers can detect the verison from EDID and populate fields which are applicable in that respective version
d42 has joined #wayland
slattann has quit []
<pq>
shankaru, having reserved fields in library ABI does not seem necessary to me. Even if reserved fields would later be converted into meaningful fields, an app that was developed when the fields were reserved will not be looking at them anyway.
<pq>
reserved fields are also difficult if you cannot foresee the exact type of the now-reserved fields in the future.
<pq>
the type may change the alignment of the following fields, so then you have to manually take care of that too
<shankaru>
pq: having reserved would be just to have the API future proof
<pq>
yes, that's what I'm talking about
<pq>
it's not necessary to future-proof the ABI
<pq>
but using reserved fields to future-proof the ABI is complicated and quite manual work, where one has to know the platform C ABI as well.
<shankaru>
pq: hmm, I am thinking of a situation where say a new colorimetry entry gets added
<pq>
using reserved fields approach will hit all the same problems as kernel ioctl structs, and the kernel has the botching up ioctls doc even
<shankaru>
if we have a structure capable of holiding all values defined till now, how we deal with this new entry
<pq>
we add new fields to the end of the existing struct
<pq>
we never modify or delete existing fields
<emersion>
yeah, -1 for reserved fields
<shankaru>
pq: ok, so if we have old client and new library version.
<pq>
this will be much easier to discuss on a MR with some code to point at
<shankaru>
pq: ok, got it. I think should be ok to manage. So we can drop resrved field idea
<pq>
If the library allocates the struct, then there is no problem. If the app allocates the struct and the library just fills it in, then the allocated struct size must be part of the library API.
<shankaru>
pq: how you feel client caching the parsed values, that should be ok right
<shankaru>
library parses and fills the structure and returns to client
<shankaru>
structure gets allocated by client itself
<pq>
caching seems kind of unimportant, it should be a compromise between memory consumption and work done per each API call, both of which I'd expect to be insignificant anyway.
<shankaru>
for a library, it should run in some context to do allocate memory for these structures
<pq>
in other words: what makes the code simpler for a start
<emersion>
^
<pq>
shankaru, well, do not use static global mutable data. That's a hard rule.
<pq>
a static variable is not what one would call "cache". It's global data. If it's mutable, it's bad.
rgallaispou has quit [Read error: Connection reset by peer]
<emersion>
if you really want to return a const struct managed by the parser, you can stash the struct in the parser itself and make sure it's immutable
<emersion>
(ie remains valid as long as the parser is)
<shankaru>
emersion: yeah I was actually thinking library not to even store this and allocate
<shankaru>
that should be done by client and library just fills that up
<shankaru>
my only reason for that reserved idea was to always have size compatibilty
<pq>
shankaru, are you thinking that the library API would be just a single function: int parse_edid(struct edid_info *target, void *data, size_t len) and then all the block structs and whatnot would be just fields of edid_info?
<emersion>
pq, how should we move forward? do we agree that a new library is the best course forward yet, or not?
<shankaru>
pq: not just one function, we can have multiple logical functions
<emersion>
"the block structs and whatnot would be just fields of edid_info" → that would be dangerous wrt. extensibility
<pq>
emersion, I won't object a new project, and I will participate with reviews in any case, but I left the decision to one who would do the work.
<shankaru>
like get_colorimetry_info, get_hdr_info etc
<shankaru>
so if a client is interested in only HDR for ex, he just invokes that with the defined hdr structure
rasterman has joined #wayland
<pq>
shankaru, this is too complicated to communicate clearly in irc. I think we need a tentative header file for the library to comment on.
caveman has quit [Remote host closed the connection]
<shankaru>
pq: got it, let me work with naveenk2 to share a library helper
caveman has joined #wayland
<shankaru>
pq: should we create a MR for review and discuss ?
<pq>
shankaru, you should create the new project first, so there can be a MR. :-)
<shankaru>
pq: yeah :P
<pq>
shankaru, look at how color-and-hdr started. I created an empty repository, and then everything went in via reviewed MRs from the beginning, starting with license and contribution guidelines.
<shankaru>
pq: ok, so should we create a project or discuss more before we go there ?
<pq>
sounds that you, emersion and swick all support the idea of a new project, and I'm not fundamentally against it, so sure - however
<pq>
we have to agree on the name first
<pq>
my best suggestion in that private email was libdisplay-info, would that work?
<pq>
to cover both EDID and DisplayID, and to set apart from the various "libedid" that seem to more or less exist
<shankaru>
pq: yeah, sound ok to me
<pq>
emersion, swick, is libdisplay-info ok with you?
<shankaru>
pq: I will try to get in shashank as well to hear his perspective
<pq>
we could probably use di_ as the namespace in C
<pq>
shankaru, ahh! I mistook you for shashank! Sorry.
<pq>
yes, definitely point him to all this
<emersion>
yea sounds fine to me
<pq>
shankaru, so, whoever is going to be working the most on this from be beginning should create the repository under their personal namespace in gitlab.freedesktop.org, IMO.
<pq>
fd.o admins want a project to develop a healthy community before they are comfortable giving the project its own namespace
<shankaru>
pq: No issues, yeah I agree I think we have all stakeholders in loop now.
<shankaru>
will poke shashank if he wants to take this forward and create the project, or any other volunteers between swick, emersion or Naveenk2
<emersion>
i don't mind doing the paperwork
<emersion>
(but up to you)
<shankaru>
emersion: lets close with shashank and you can create if he is also ok
<emersion>
not sure about di_status but the rest looks good
<pq>
it's very incomplete, too
<pq>
I literally made it up just now
<pq>
for example, it is going to need some form of logging API so that it can match edid-decode's validation messages
<shankaru>
pq: looks good to me, we can have multiple helpers like ur current physical_width_height
<shankaru>
so idea looks good
<mriesch>
hi all. i have been following the edid-decode/libedid/... discussion a bit and was wondering if this new project could also generate/encode an edid.
<emersion>
mriesch: what's your use-case?
<emersion>
if anything, i don't think this will be a focus short- or middle-term
<pq>
mriesch, my immediate feeling about that is "no". I suspect it would essentially double all the code needed, and require a very different API as well.
<mriesch>
if anything this feature is probably more interesting for the linux-media people, e.g. for boards with hdmi receivers
<pq>
mriesch, don't they already have anything for that?
<mriesch>
but it could also help for testing and (initially) for api design (symmetry is always good :-)
<pq>
I think the linux.tv database of 60 000 recorded EDID files is testing enough. ;-)
<pq>
and real EDIDs are notorious to be broken and wild
alarumbe has quit [Ping timeout: 480 seconds]
<mriesch>
there are some tools that generate edids (windows tools, web tools) but i am not aware of a solid open source software project
<pq>
I don't think API symmetry would be a thing really, not with the parsing high-level API at least. A piece of high-level information could come from several different optional blocks and fields.
<pq>
mriesch, the testing plan so far is to use the EDID sample database already collected at linux.tv and with edid-decode, and ensure we match edid-decode behavior.
<naveenk2>
pq: emersion: shankaru: +1 for idea of creating a new project, I actually started a bit of it earlier (libedid/README.md at main · NaveenKumar-Intel/libedid (github.com)) but yeah changing the name to libdisplay-info sounds good as well. If all agrees, I am ready to create a new project and adding initial library helper draft
<pq>
I think that can be done incrementally as well, by ensuring that the diff to edid-decode output never grows.
<pq>
naveenk2 or shankaru, can you email shashank and cc me, emersion, swick and anyone else, and agree on who does what next?
<pq>
and also where they intend to host the project
<mriesch>
pq, testing with many real edids is certainly a good thing, but doesn't one require faulty samples as well to check the error cases?
<pq>
mriesch, real EDIDs might well cover all errors :-D
<mriesch>
fair point :-)
<pq>
more seriously, that's a good point too
<mriesch>
as to the api design, i understand that a low-level and a high-level api was envisaged at some point. is this still the plan?
<emersion>
see above -- yes
<pq>
I'm not sure those actually require developing an EDID creation library though. One could probably use whatever tools already exist (or a hex editor) to craft the remaining error triggering blobs.
<naveenk2>
pq: shankaru: sure I will start a mail thread copying u all
<pq>
naveenk2, thanks!
<mriesch>
then probably the low-level api could be symmetric and allow for creation of an edid. i agree that the high-level api will suffer from ambiguities at some point (more than one way to specify a certain resolution, for example)
<mriesch>
pq, indeed, and come to think of it i am not sure the library should generate faulty edids in the first place
<mriesch>
anyway, i could not find a good edid generator for linux and maybe we can keep this use case in mind during the design of the new project
<dottedmag>
designs for parsing and serializing are often in tension. just saying.
<swick>
fuzzing the lib should be sufficient for the error cases hopefully
<swick>
quirks could be applied explicitly by operating on the context (i.e. struct di_info)
<swick>
as well as a validation pass
<swick>
validation will have to happen at parsing time to some degree but making sure all the fields are valid and in valid combinations could be done in a separate pass
<swick>
the main thing about the high level API I'm a bit unsure of is that some questions might require the library to know the mode, including the AVI InfoFrames which are applied
<emersion>
"Driver support" is inaccurate
<swick>
pq: interesting, it is
<emersion>
it only looks at the latest snapshot
<pq>
emersion, I mean, I don't recall seeing that property ever before, wonder if it's some downstream hack
<pq>
HDR_OUTPUT_METADATA is the upstream thing we use
<pq>
I was curious if intel ever exposed HDR_OUTPUT_METADATA since it doesn't for me. Looks like it does, so maybe I'm just on an old kernel.
<emersion>
hm actually it seems like drmdb does the right thing here, nvm
<pq>
amd card currently reserved purely for testing weston
<swick>
and AMD doesn't expose the Colorspace property
<swick>
pq: btw, have you seen a wider color gamut when you set HDR_OUTPUT_METADATA?
<pq>
I'm not sure
<pq>
I'm not sure I've seen WCG live, at least in a way that I recognized it.
<pq>
also compared to my normal monitors, it's hard to say if my HDR monitor is WCG or just with different dynamic range
<pq>
Could AMD set the colorimetry infoframe to BT.2020 if HDR_OUTPUT_METADATA is PQ or HLG to make it work in the usual case?
<pq>
I almost wish I could see what's going on in the cable
rgallaispou has joined #wayland
<ofourdan>
err, does wayland (the library) follows a release schedule like one a year or twice a year or does it get a new release whenever needed?
eroux_ has quit [Ping timeout: 480 seconds]
alarumbe has joined #wayland
lagash has quit [Remote host closed the connection]
lagash has joined #wayland
ahartmetz has quit [Ping timeout: 480 seconds]
shashanks has joined #wayland
<emersion>
ofourdan: whenever needed
<ofourdan>
thanks!
<swick>
pq: sure, but implementing the colorimetry infoframe is the only thing you have to do, the drm helpers do all the Colorspace property stuff for you
<pq>
swick, right, but that wouldn't be the first shortcut in amdgpu... I forget what the first one I heard about was.
shashank_sharma has joined #wayland
<pq>
oh, right: the CRTC GAMMA property controls whether the hardware does hw plane blending with sRGB linearization/delinearization or as-is, IIRC.
<pq>
so setting NULL GAMMA behaves differently than setting identity curve to GAMMA
shashanks has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
shashank_sharma is now known as shashanks
<shashanks>
pq: actually CRTC gamma can be called the output curve post plane blending, which means that a NULL(0) gamma can blank the screen output in many HWs
ahartmetz has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
cvmn has quit [Remote host closed the connection]
cvmn has joined #wayland
jgrulich has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
Lucretia has quit []
zebrag has joined #wayland
<shashanks>
pq: I have sent V2 of libedid, with new high level APIs
<shashanks>
this addresses some of your review comments, has 28 new APIs to extract specific information from the EDID, and returns a transparent ptr for a client
<shashanks>
A sample test application (test-libedid-api.c) shows simple demo usages as well
rgallaispou has quit [Read error: Connection reset by peer]
slattann has joined #wayland
hergertme has quit [Remote host closed the connection]
hergertme has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
cabal704 has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
cabal704 has quit [Quit: WeeChat 3.4.1]
slattann has quit []
eroux has joined #wayland
<swick>
shankaru shashanks pq emersion naveenk2: should we just create the libdisplay-info repo on gitlab.fdo and then create MRs, probably basing them off https://github.com/contactshashanksharma/libedid ?
<swick>
emersion: did you offer to create such a repo? ;)
<emersion>
yup, but didn't get an ack
shankaru has quit [Read error: Connection reset by peer]
<swick>
I would be on board
shankaru has joined #wayland
<swick>
if you don't do it I will
<shashanks>
swick, emersion: sounds good to me
<emersion>
cool! i'm heading out, but will create when i get back
<swick>
perfect, thanks!
d42 has quit [Ping timeout: 480 seconds]
d42 has joined #wayland
shankaru has quit [Quit: Leaving.]
cvmn has joined #wayland
caveman has quit [Ping timeout: 480 seconds]
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]