07:32 pq: orowith2os[m], wl_drm is/was a Mesa internal private protocol extension that was not supposed to be used outside of Mesa sources. It was made for the EGL Wayland platform long before zwp_linux_dmabuf was a thing. Also before DRM render nodes were as usable as today. And before DRM format modifiers, IIRC.
07:34 MrCooper: zzag: yes, Xwayland still requires wl_drm
07:37 MrCooper: orowith2os[m]: you're still a relative newcomer to these communities (with no contribution track record I'm aware of), and I've warned you before that your approach to establishing yourself in these communities isn't great; IMHO it's bound to result in conflicts like the above
07:40 pq: MrCooper, does wl_drm still have something that's not in zwp_linux_dmabuf that Xwayland needs?
07:40 orowith2os[m]: MrCooper: the above conflicts would've happened anyways, but I should definitely try and separate myself from those troublesome people where possible. Guess we'll see how far I can get, considering I'm attempting to contribute to more of the lower level bits where they're common.
07:42 MrCooper: orowith2os[m]: sounds like you're denying any responsibility of your own, again not a good sign
07:43 orowith2os[m]: it's hard for me to try and put it all into words without making it seem like such, but definitely not my intention
07:44 orowith2os[m]: if i can improve, point me to where, and I can try
07:45 MrCooper: one advice would be to focus on actual contributions rather than trying to influence projects where you're not an established contributor
07:45 pq: orowith2os[m], I recall seeing harsh wording from you in Mastodon that I wish you didn't use. It gives me an awkward feeling of not wanting to talk to you, but also it's really hard for me to leave good questions unanswered.
07:46 orowith2os[m]: MrCooper: I'll see what I can do :) most of my time right now is really spent horribly, I'm stretching myself too thin and not getting anything done....
07:46 orowith2os[m]: all talk, no action
07:48 orowith2os[m]: pq: anything to jog my memory?
07:49 MrCooper: I'm constantly struggling with that as well, just be aware that "all talk, no action" is kind of like the definition of peanut gallery, which tends to be irritating for people doing the heavy lifting
07:49 pq: I've been there. One possible remedy is to stop some of the message delivery: part chat channels, stop email deliver from mailing list, etc. and the hardest part is to choose to not get involved in topics too widely.
07:50 orowith2os[m]: mm, I'll sort out some content-type changes first (that shouldn't need too many changes) and look at focusing on stuff I can do, and clearing out my backlog of stuff I can't
07:51 orowith2os[m]: and on that topic: should it be that the content-type protocol is modified to state that, when an invalid type is set, the error is silently ignored?
07:51 orowith2os[m]: rather than changing it to return an error or anything
07:52 orowith2os[m]: it appears as if the protocol originally wasn't designed with expansion in mind, so this is a bit of a hack to work around that, but would need very little work to do
07:53 pq: orowith2os[m], the use of word "stupid", especially with people, "shit", "fuck off", "BS". These are direct quotes from a post of yours.
07:53 orowith2os[m]: ah, that one
07:53 jadahl: orowith2os[m]: if this is about the "sensitive" i.e. something for bank apps to use, then I'd advise against using content type as a basis, it's pretty orthogonal
07:54 orowith2os[m]: sensitive is a separate problem
07:54 orowith2os[m]: and one I agree that should be solved separately
07:54 orowith2os[m]: this is just for any future additions to it - one such thing I'm considering is a "document" content type for e.g. document viewers
07:54 pq: unpleasant things are more easily remembered than pleasant ones, unfortunately - you have many posts without the issue too
07:55 orowith2os[m]: pq: I do tend to be foul mouthed a lot, but I guess I should look at trying and using it in less provocative contexts?
07:55 orowith2os[m]: (like being annoyed at hard to debug runtime errors....)
07:55 pq: I think it would be best kept private, really.
07:56 pq: vent to friends in private
07:56 jadahl: orowith2os[m]: get a rubber duck and curse at it instead of Matrix and mastodon
07:56 privacy: lol
07:56 orowith2os[m]: both good suggestions, will do :)
07:56 orowith2os[m]: nag me if yall are ever annoyed
07:57 pq: thanks you
07:57 pq: -s
07:59 pq: my problem with content type alike tagging is establishing a common understanding of what it means: how is it possible to use it consistently in both clients and compositors, so that results are expected?
08:00 orowith2os[m]: one problem to consider is, should one expect any results?
08:00 pq: Wayland is a protocol, and a protocol is the common language between two software components. If a word in the language means someone to one side, and is utterly arbitrary to the other side, then what does that word actually communicate?
08:00 pq: *something
08:00 orowith2os[m]: as-is, it's mainly something a compositor would use to help set the content-type for the display to optimize itself for
08:00 orowith2os[m]: but it can be useful for more than that
08:01 pq: staging/content-type actually does manage to set some expectations by mentioning e.g. latency
08:02 orowith2os[m]: mm, I guess we can always settle for "some expectations"
08:02 orowith2os[m]: and not all the expectations
08:02 pq: yes, some kind of common understand of what it is roughly about
08:02 pq: *understanding
08:03 orowith2os[m]: one use case I'd have for content-type would be assisting in window management
08:03 pq: ok
08:03 jadahl: dont do that please :P
08:03 orowith2os[m]: which is also why I'm trying to update it a bit
08:03 jadahl: thats repeating a big mistake called X11 window management
08:03 pq: that seems very orthogonal to staging/content-type to me
08:04 orowith2os[m]: jadahl: how so?
08:04 jadahl: it has arbitrary "tagging" of the type of content a window has, and its a horror story to deal with
08:04 ascent12: Wayland protocols are written to be extremely specific about what they're trying to achieve, and not allow for any wiggle room, at least on the client side.
08:05 ascent12: You're never going to get compositor developers to accept anything too broad.
08:05 jadahl: orowith2os[m]: https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm46113623159632
08:05 jadahl: I do not want to deal with that except when best-effort-supporting X11 clients
08:05 orowith2os[m]: jadahl: an actual implementation I see for this would be marking a fullscreen surface as "presentation", and e.g. gnome-shell could automatically put it into a dedicated presentation workspace that gets put onto a projector
08:06 orowith2os[m]: it's not as explicit as saying "hey, put me on X display", but would also work
08:07 orowith2os[m]: and I'm not sure if this is relevant too much, but would leak less information to clients about the setup
08:07 jadahl: there are probably better ways than adding a _NET_WM_WINDOW_TYPE_PRESENTATION
08:08 jadahl: the first thing that comes to mind is "fullescreen_on_something_like(PRESENTATION_DEVICE)"
08:08 orowith2os[m]: both would work here
08:08 orowith2os[m]: I'm just more in favour of a content type since it already exists, and can be more flexible
08:08 pq: The tag "game" would be meaningless if its description didn't talk about latency, and the whole enum be in the context of presentation mechanics like quality vs. performance, and fast vs. slow moving. I'm sure there are games that would match better with "photo" or "video" than "game" in that enum. Visual novel kind of things maybe.
08:09 jadahl: orowith2os[m]: you'll have to have a really really good reason to reintroduce _NET_WM_WINDOW_TYPE for that
08:10 orowith2os[m]: ah, but I don't need one
08:10 orowith2os[m]: it already has been introduced
08:10 orowith2os[m]: and implemented in some clients, like mpv
08:10 jadahl: i don't agree content-type is similar to _NET_WM_WINDOW_TYPE here
08:10 orowith2os[m]: comparing those two is something I'm not quite understanding
08:11 jadahl: but adding window management logic expectations that affects positioning, sizing, etc, would amke it so
08:11 pq: staging/content-type so far is very different from _NET_WM_WINDOW_TYPE, because of that the enum contains
08:12 pq: it's not an arbitrary tag anything with anything system, it is quite specific to the existing choices in the enum, and even when it explicitly avoids referring to HDMI spec, it very much carries over the same enum.
08:12 orowith2os[m]: jadahl: is it bad that I'm viewing content-type in a not-so-specific PoV here?
08:12 jadahl: not sure what you mean
08:13 orowith2os[m]: I'm not liking trying to push content-type into something that needs to give clients hard expectations of what a compositor would do
08:13 orowith2os[m]: in my eyes, this is just another piece of information a compositor would use to optimize its behavior
08:13 orowith2os[m]: not something to be used exclusively
08:14 jadahl: so you want to add a "presentation" type that has zero expectations? that has the problem pq mentioned earlier
08:14 orowith2os[m]: for example, a client might set the video content type in the hopes that it gets displayed better, but that isn't exclusive to e.g. an HDR protocol
08:14 pq: Right now, I think the context and scope of staging/content-type is fairly well established, and it likely works for what it has today. But expanding the scope and context would IMO break it.
08:15 jadahl: yea
08:15 orowith2os[m]: already, expanding it would literally break it
08:15 orowith2os[m]: it wasn't originally designed to handle additions to the enum, looks like
08:15 pq: I don't mean protocol mechanics wise, I mean break it semantically
08:15 orowith2os[m]: mm
08:16 pq: mechanics can always be fixed by adding new requests and events with a version bump
08:16 orowith2os[m]: jadahl: I want to set a "presentation" type that gives me some reasonable expectations, but nothing *guaranteed*
08:16 jadahl: orowith2os[m]: handling adding enums is done with Wayland itself. you bind a specific version, and all enums in that version needs to be handled.
08:17 orowith2os[m]: I don't want to have to guarantee that a surface marked as "presentation" gets put onto a presentation display - that's for the compositor to decide, if it even wants to handle in the first place
08:17 pq: orowith2os[m], unguaranteed expectations are fine, as long as they are spec'd.
08:17 pq: "everything you can imagine" not so much
08:17 orowith2os[m]: maybe I'm just going on this side bit because I'm getting a bit turned around
08:18 orowith2os[m]: let me write up an actual example of what the description for this would be first
08:19 ascent12: Wasn't the content-type protocol used to just represent the "content type" DRM property?
08:19 ascent12: If the client happens to be fullscreened
08:19 pq: ascent12, that's where it originated
08:20 MrCooper: for actual presentations, to me it makes more sense to just choose a specific output in the application, instead of switching to systems settings to set the presentation output and then switching back to the app
08:20 orowith2os[m]: yes, no reason to have it be limited to that, and was in fact already separated more when it was originally designed
08:20 orowith2os[m]: mmm
08:20 orowith2os[m]: like I said, would also work, and might actually be useful for more than just presentation - but also, having more hints for the compositor to work with isn't bad
08:21 orowith2os[m]: they're not exclusive here
08:21 ascent12: Definitely sounds like it deserves its own separate protocol to me.
08:21 jadahl: either way, any discussion here is a bit useless without having a intended user with a sketched out UX design. only then does it make sense to think about how to achieve that.
08:22 pq: MrCooper, OTOH, a compositor could have heuristics for picking the presentation output that would be 99% correct for laptops. And the compositor can make sure nothing else goes to that output.
08:22 pq: ..accidentally
08:22 MrCooper: fair
08:23 jadahl: there are some design mockups for that (exclusive presentation device) somewhere on gnome infra, but not sure how outdated
08:24 orowith2os[m]: "The "presentation" content type describes content which is displayed in a slow fashion, such as image slideshows and presentations. Content may be displayed on, for example, a presentation display in a meeting. Where scaling is needed, scaling methods to ensure readable text may be used. "
08:24 orowith2os[m]: needs minor tweaks, but that's the idea I have in mind
08:25 pq: orowith2os[m], what if I want to show a video? Or a demo (as in demo scene)?
08:25 orowith2os[m]: in those cases, the "video" content type would be more appropriate
08:25 pq: but I still want it in the presentation output
08:26 orowith2os[m]: mm, true, and also why I mentioned that this and an explicit display placement protocol aren't mutually exclusive
08:26 orowith2os[m]: though the latter could end up removing the need for this
08:26 pq: yes
08:28 orowith2os[m]: I guess it's generally preference here. Do we allow the compositor to have more wiggle room, and maybe even optimize content better, or make the client explicit about those things?
08:28 orowith2os[m]: *and/or
08:29 orowith2os[m]: more hints are always good, and in the worst case, this type ends up going unused, and as such, ignored by compositors
08:29 orowith2os[m]: it's pretty non-harmful
08:31 orowith2os[m]: also, the compositor could also infer that the content may want to be displayed with e.g. a video-esque optimization from how often it gets requests to update the content
08:31 orowith2os[m]: so you're also not locking yourself in here
08:31 orowith2os[m]: these are all hints, not guarantees
08:37 orowith2os[m]: another reason to have a presentation content type: better power optimizations
08:38 orowith2os[m]: a compositor could naturally scale its update frequency down when it doesn't get frame updates often, can further have reason to do so with content type hints, and vice versa
08:39 pq: I disagree with "more hints are always good" and "non-harmful"; they expand the API surface and make it harder to understand and keep old apps working well that already started using them for their (potentially conflicting) intentions.
08:40 orowith2os[m]: if a type is ever deemed as not useful, or used wrong, it could always just be ignored
08:40 orowith2os[m]: same goes for if it's superceded by something more dedicated
08:40 pq: that would regress those who used it already
08:42 pq: it would also burden developers who have to wade through "this is deprecated" parts of specs, as we cannot delete definitions from XML.
08:43 pq: My point is that unused parts of spec do not have a zero cost.
08:48 ascent12: A lot of specs are written to give the compositor the final say on everything, and it could easily lie about a whole bunch of things, but without some kind of reasonable expected behaviour, the spec would also become kind of useless to clients.
11:00 zamundaaa[m]: Dallas Strouse (she/her) 🧑‍🏫: to repeat that again here: content type is about the *dynamic* content of a window - a presentation app could show text most of the time and then a video, and reflect that to the compositor
11:01 zamundaaa[m]: For presentations you want something more static, something that can actually be used for window management. Maybe you'd even want a surface role specifically for that
11:15 daniels: I actually do think there's something to being able to specify the update rate: presentation apps could specify that they can tolerate quite a bit of latency, whereas media apps could specify their actual target frame rate, and both of those are useful things for the compositor to know
11:15 daniels: whether or not that should be entangled with a content type I'm not sure
11:16 daniels: one thing to be cautious with 'presentation' mode vs. output selection is that all presentation apps come with a 'swap displays' button, so you'd need to be able to support that ...
11:18 zamundaaa[m]: daniels: the swap button is just a workaround for the app not knowing which display is the presentation display
11:18 zamundaaa[m]: So I'm not convinced it's actually needed
11:19 daniels: zamundaaa[m]: unless it's not something which can be easily divined, because both the presenter's display and the presentation display are external
11:19 pq: I'd put a "switch display" button in the compositor/desktop UI when 'presentation' mode is being used by any client, so that it can e.g. move *all* windows when wanted.
11:20 daniels: pq: hm, so the compositor gets the UI of being able to switch the displays as well as exiting presentation mode?
11:21 pq: clients choose to use presentation mode; compositor holds the config of which one is the presentation output; when presentation mode is being used, show a desktop UI button to fix it if it chose a wrong output, and remember the choice.
11:22 pq: when presentation more is not in use, the presentation output can still be selected in display config UI
11:22 pq: the main value-add is that the compositor can automatically remove all windows from the presentation output that do not belong there.
11:23 pq: and make sure windows don't accidentally appear in the presentation output for all audience to laugh at
11:24 pq: that's for multi-head
11:25 pq: if there is only one output, then there is no need for switch, but there might be a need for an exit gesture
11:25 pq: if the compositor is preventing non-presentation windows from popping on top
11:28 zamundaaa[m]: Yeah there's plenty of things a compositor could do
11:30 pq: the single output case could also be just the regular fullscreen mode, since there is nothing more to do for a presentation
11:31 daniels: pq: I think the compositor can have 'presentation means exclusive' policy without also having to have UI to go along with it
11:32 pq: the UI exists solely for the cases where heuristics get the output choice wrong
11:33 pq: I would not mandate any UI by protocol spec, no, but I also would not include "switch outputs" in that protocol.
11:33 pq: a full-featured desktop would likely want the UI though
11:39 Net147: how would I go about scaling the display in Weston only horizontally rather than both horizontally/vertically? I have a display where the pixels are rectangular and I want to correct the aspect ratio but scaling only in one dimension.
11:39 Net147: *by scaling only in one dimension.
11:41 kennylevinsen: Having the display server scale that in post would likely make everything rather blurry
11:44 pq: Net147, would choosing a CEA video mode help?
11:46 pq: Net147, see 'man weston-drm' for the "mode" key with aspect ratio
11:47 pq: Net147, if that's doesn't help, you probably need to hack the code.
11:49 pq: kennylevinsen, would fractional scaling handle non-square output pixels?
12:04 kennylevinsen: pq: it does not have a mechanisms to specify a non-square ratio, but it's just viewporter
12:04 Net147: the display is 800x480. I was thinking if Weston could present a 862x480 screen and then scaling down horizontally to 800 when it is display that would fix it.
12:06 Net147: kennylevinsen, is there a way to specify a viewporter for Chromium without having to modify Chromium?
12:06 kennylevinsen: So it is possible to submit a scaled buffer that does not preserve source aspect ratio, if such scale could be communicated
12:07 kennylevinsen: No, it is a Wayland protocol. Either chromium or a hacky proxy would have to send the appropriate messages
12:07 kennylevinsen: I guess a hacked up libwayland is also a possibility, but the goal is that the compositor sees Chromium ask for a viewport configured correctly and updated whenever the window changes size
12:08 Net147: I mean ideally I want it to apply to the whole screen including the Weston toolbar, etc., but I can settle for applying it to a single client if that is easier
12:08 Net147: I was thinking of perhaps hacking Weston to only apple scale to x and not y
12:10 Net147: *apply
12:14 pq: Net147, so choosing a CEA mode with non-square pixels doesn't work for your case?
12:16 Net147: pq, the only mode the display supports is 800x480. I am not sure how to choose a CEA mode that would give 862x480 screen that is rendered at 800x480 to display.
12:16 pq: ok
12:16 pq: hacking weston it is, then
12:17 pq: all the functionality already exists I believe, the only thing missing is controlling it
12:17 Net147: pq, do you think having the scale option to only apply on one axis would be the easiest?
12:18 pq: no, because the scale is communicated to clients, that would be wrong
12:19 pq: weston_output contains the matrices and regions used to convert between the global coordinate system and the output physical pixels coordinate system
12:19 pq: you'd set your panel native resolution in the video mode, and hack weston_output members to configure the necessary scaling
12:22 pq: Net147, I would probably start with hacking weston_output_update_matrix() and weston_output_transform_scale_init(), they seem the most relevant
12:23 pq: current_mode is the video mode resolution in hardware, so your panel native resolution with non-square pixels
12:23 pq: output->width,height are the logical output size in global coordinate system in square pixels
12:24 pq: and matrix and inverse_matrix are the conversions between the two
12:24 pq: getting all those set might be enough
12:25 Net147: pq, okay thanks for the help. I will try it tomorrow.
12:25 kennylevinsen: or: just look at the display at a slight angle to compensate
13:00 jadahl: d_ed[m]: fancy compositor handover demonstration
13:01 kennylevinsen: I was not super excited for crash recoveryg but handover is genuinely cool
13:03 d_ed[m]: Thanks!
13:09 kennylevinsen: d_ed[m]: how does the reconnect logic distinguish between compositor gone due to exit and compositor gone due to crash?
13:10 MrCooper: gone due to exit means display socket is gone as well?
13:11 d_ed[m]: that's right
13:11 d_ed[m]: the handoff demo is ever so slightly "faked" to not have that check
13:12 kennylevinsen: deception?!
13:13 kennylevinsen: But I guess that makes sense. Not sure how I feel about a "wayland socket manager" parent, but neat regardless.
15:51 orowith2os[m]: daniels: re the idea of a client tolerating higher latency, was there some frame timing work that would address that?
15:52 orowith2os[m]: But also, I guess a client could also dynamically change the content type to video if e.g. a video were embedded in a presentation
15:52 orowith2os[m]: I forgot that was a possibility
15:57 orowith2os[m]: So stating that a presentation would get displayed with less latency optimizations would work too
15:58 orowith2os[m]: (and may also need an explicit note that the content type can change at any time for a surface, if it's not clear enough)
22:52 wlb: weston Issue #803 closed \o/ (`weston: ../libweston/output-capture.c:398: weston_output_pull_capture_task: Assertion `csi->width == width' failed.` https://gitlab.freedesktop.org/wayland/weston/-/issues/803)