ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
utsweetyfish has quit [Remote host closed the connection]
utsweetyfish has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
PuercoPop has joined #wayland
andyrtr_ has joined #wayland
carlos_ has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
Brainium has quit [Quit: Konversation terminated!]
PuercoPop has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
tjaden has quit [Quit: leaving]
tjaden has joined #wayland
Lyude has quit [Ping timeout: 480 seconds]
Lyude has joined #wayland
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
tzimmermann has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
rv1sr has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
sima has joined #wayland
rasterman has joined #wayland
sevz has quit [Quit: WeeChat 4.0.4]
carlos_ has joined #wayland
privacy has joined #wayland
iomari891 has joined #wayland
paulk has quit [Quit: WeeChat 3.0]
paulk has joined #wayland
<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.
<MrCooper>
zzag: yes, Xwayland still requires wl_drm
<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
<pq>
MrCooper, does wl_drm still have something that's not in zwp_linux_dmabuf that Xwayland needs?
<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.
<MrCooper>
orowith2os[m]: sounds like you're denying any responsibility of your own, again not a good sign
<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
<orowith2os[m]>
if i can improve, point me to where, and I can try
<MrCooper>
one advice would be to focus on actual contributions rather than trying to influence projects where you're not an established contributor
<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.
<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....
<orowith2os[m]>
all talk, no action
<orowith2os[m]>
pq: anything to jog my memory?
<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
andyrtr has quit [Ping timeout: 480 seconds]
<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.
<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
<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?
<orowith2os[m]>
rather than changing it to return an error or anything
<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
<pq>
orowith2os[m], the use of word "stupid", especially with people, "shit", "fuck off", "BS". These are direct quotes from a post of yours.
<orowith2os[m]>
ah, that one
<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
<orowith2os[m]>
sensitive is a separate problem
<orowith2os[m]>
and one I agree that should be solved separately
<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
<pq>
unpleasant things are more easily remembered than pleasant ones, unfortunately - you have many posts without the issue too
<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?
<orowith2os[m]>
(like being annoyed at hard to debug runtime errors....)
<pq>
I think it would be best kept private, really.
<pq>
vent to friends in private
<jadahl>
orowith2os[m]: get a rubber duck and curse at it instead of Matrix and mastodon
<privacy>
lol
<orowith2os[m]>
both good suggestions, will do :)
<orowith2os[m]>
nag me if yall are ever annoyed
<pq>
thanks you
<pq>
-s
<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?
rgallaispou has joined #wayland
<orowith2os[m]>
one problem to consider is, should one expect any results?
<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?
<pq>
*something
<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
<orowith2os[m]>
but it can be useful for more than that
<pq>
staging/content-type actually does manage to set some expectations by mentioning e.g. latency
<orowith2os[m]>
mm, I guess we can always settle for "some expectations"
<orowith2os[m]>
and not all the expectations
<pq>
yes, some kind of common understand of what it is roughly about
<pq>
*understanding
<orowith2os[m]>
one use case I'd have for content-type would be assisting in window management
<pq>
ok
<jadahl>
dont do that please :P
<orowith2os[m]>
which is also why I'm trying to update it a bit
<jadahl>
thats repeating a big mistake called X11 window management
<pq>
that seems very orthogonal to staging/content-type to me
<orowith2os[m]>
jadahl: how so?
<jadahl>
it has arbitrary "tagging" of the type of content a window has, and its a horror story to deal with
<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.
<ascent12>
You're never going to get compositor developers to accept anything too broad.
<jadahl>
I do not want to deal with that except when best-effort-supporting X11 clients
<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
qyliss has quit [Quit: bye]
<orowith2os[m]>
it's not as explicit as saying "hey, put me on X display", but would also work
<orowith2os[m]>
and I'm not sure if this is relevant too much, but would leak less information to clients about the setup
<jadahl>
there are probably better ways than adding a _NET_WM_WINDOW_TYPE_PRESENTATION
qyliss has joined #wayland
<jadahl>
the first thing that comes to mind is "fullescreen_on_something_like(PRESENTATION_DEVICE)"
qyliss has quit [Remote host closed the connection]
<orowith2os[m]>
both would work here
<orowith2os[m]>
I'm just more in favour of a content type since it already exists, and can be more flexible
<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.
<jadahl>
orowith2os[m]: you'll have to have a really really good reason to reintroduce _NET_WM_WINDOW_TYPE for that
<orowith2os[m]>
ah, but I don't need one
<orowith2os[m]>
it already has been introduced
<orowith2os[m]>
and implemented in some clients, like mpv
<jadahl>
i don't agree content-type is similar to _NET_WM_WINDOW_TYPE here
qyliss has joined #wayland
<orowith2os[m]>
comparing those two is something I'm not quite understanding
<jadahl>
but adding window management logic expectations that affects positioning, sizing, etc, would amke it so
<pq>
staging/content-type so far is very different from _NET_WM_WINDOW_TYPE, because of that the enum contains
<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.
<orowith2os[m]>
jadahl: is it bad that I'm viewing content-type in a not-so-specific PoV here?
<jadahl>
not sure what you mean
<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
<orowith2os[m]>
in my eyes, this is just another piece of information a compositor would use to optimize its behavior
<orowith2os[m]>
not something to be used exclusively
<jadahl>
so you want to add a "presentation" type that has zero expectations? that has the problem pq mentioned earlier
<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
<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.
<jadahl>
yea
<orowith2os[m]>
already, expanding it would literally break it
<orowith2os[m]>
it wasn't originally designed to handle additions to the enum, looks like
<pq>
I don't mean protocol mechanics wise, I mean break it semantically
<orowith2os[m]>
mm
<pq>
mechanics can always be fixed by adding new requests and events with a version bump
<orowith2os[m]>
jadahl: I want to set a "presentation" type that gives me some reasonable expectations, but nothing *guaranteed*
<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.
<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
<pq>
orowith2os[m], unguaranteed expectations are fine, as long as they are spec'd.
<pq>
"everything you can imagine" not so much
<orowith2os[m]>
maybe I'm just going on this side bit because I'm getting a bit turned around
<orowith2os[m]>
let me write up an actual example of what the description for this would be first
<ascent12>
Wasn't the content-type protocol used to just represent the "content type" DRM property?
<ascent12>
If the client happens to be fullscreened
<pq>
ascent12, that's where it originated
<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
<orowith2os[m]>
yes, no reason to have it be limited to that, and was in fact already separated more when it was originally designed
<orowith2os[m]>
mmm
<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
<orowith2os[m]>
they're not exclusive here
<ascent12>
Definitely sounds like it deserves its own separate protocol to me.
<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.
<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.
<pq>
..accidentally
<MrCooper>
fair
<jadahl>
there are some design mockups for that (exclusive presentation device) somewhere on gnome infra, but not sure how outdated
<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. "
mblenc has joined #wayland
<orowith2os[m]>
needs minor tweaks, but that's the idea I have in mind
<pq>
orowith2os[m], what if I want to show a video? Or a demo (as in demo scene)?
<orowith2os[m]>
in those cases, the "video" content type would be more appropriate
<pq>
but I still want it in the presentation output
<orowith2os[m]>
mm, true, and also why I mentioned that this and an explicit display placement protocol aren't mutually exclusive
<orowith2os[m]>
though the latter could end up removing the need for this
<pq>
yes
<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?
<orowith2os[m]>
*and/or
<orowith2os[m]>
more hints are always good, and in the worst case, this type ends up going unused, and as such, ignored by compositors
<orowith2os[m]>
it's pretty non-harmful
<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
<orowith2os[m]>
so you're also not locking yourself in here
<orowith2os[m]>
these are all hints, not guarantees
<orowith2os[m]>
another reason to have a presentation content type: better power optimizations
<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
<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.
<orowith2os[m]>
if a type is ever deemed as not useful, or used wrong, it could always just be ignored
<orowith2os[m]>
same goes for if it's superceded by something more dedicated
<pq>
that would regress those who used it already
<pq>
it would also burden developers who have to wade through "this is deprecated" parts of specs, as we cannot delete definitions from XML.
<pq>
My point is that unused parts of spec do not have a zero cost.
fmuellner has joined #wayland
<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.
mriesch has quit [Remote host closed the connection]
cmichael has joined #wayland
andyrtr has joined #wayland
mriesch has joined #wayland
Halano has joined #wayland
Halano has left #wayland [#wayland]
tent405 has quit [Ping timeout: 480 seconds]
<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
<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
nerdopolis has joined #wayland
privacy has quit [Quit: Leaving]
<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
<daniels>
whether or not that should be entangled with a content type I'm not sure
<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 ...
<zamundaaa[m]>
daniels: the swap button is just a workaround for the app not knowing which display is the presentation display
<zamundaaa[m]>
So I'm not convinced it's actually needed
<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
<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.
<daniels>
pq: hm, so the compositor gets the UI of being able to switch the displays as well as exiting presentation mode?
<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.
<pq>
when presentation more is not in use, the presentation output can still be selected in display config UI
<pq>
the main value-add is that the compositor can automatically remove all windows from the presentation output that do not belong there.
<pq>
and make sure windows don't accidentally appear in the presentation output for all audience to laugh at
<pq>
that's for multi-head
<pq>
if there is only one output, then there is no need for switch, but there might be a need for an exit gesture
<pq>
if the compositor is preventing non-presentation windows from popping on top
<zamundaaa[m]>
Yeah there's plenty of things a compositor could do
<pq>
the single output case could also be just the regular fullscreen mode, since there is nothing more to do for a presentation
<daniels>
pq: I think the compositor can have 'presentation means exclusive' policy without also having to have UI to go along with it
<pq>
the UI exists solely for the cases where heuristics get the output choice wrong
<pq>
I would not mandate any UI by protocol spec, no, but I also would not include "switch outputs" in that protocol.
Company has joined #wayland
<pq>
a full-featured desktop would likely want the UI though
<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.
<Net147>
*by scaling only in one dimension.
<kennylevinsen>
Having the display server scale that in post would likely make everything rather blurry
<pq>
Net147, would choosing a CEA video mode help?
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
Net147, see 'man weston-drm' for the "mode" key with aspect ratio
<pq>
Net147, if that's doesn't help, you probably need to hack the code.
<pq>
kennylevinsen, would fractional scaling handle non-square output pixels?
Moprius has joined #wayland
<kennylevinsen>
pq: it does not have a mechanisms to specify a non-square ratio, but it's just viewporter
<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.
<Net147>
kennylevinsen, is there a way to specify a viewporter for Chromium without having to modify Chromium?
<kennylevinsen>
So it is possible to submit a scaled buffer that does not preserve source aspect ratio, if such scale could be communicated
<kennylevinsen>
No, it is a Wayland protocol. Either chromium or a hacky proxy would have to send the appropriate messages
<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
<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
<Net147>
I was thinking of perhaps hacking Weston to only apple scale to x and not y
Cyrinux9474 has quit []
Moprius has quit [Quit: bye]
<Net147>
*apply
manuel1985 has quit [Quit: Leaving]
<pq>
Net147, so choosing a CEA mode with non-square pixels doesn't work for your case?
rgallaispou has quit [Ping timeout: 480 seconds]
<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.
<pq>
ok
<pq>
hacking weston it is, then
rgallaispou has joined #wayland
andyrtr_ has joined #wayland
<pq>
all the functionality already exists I believe, the only thing missing is controlling it
<Net147>
pq, do you think having the scale option to only apply on one axis would be the easiest?
<pq>
no, because the scale is communicated to clients, that would be wrong
<pq>
weston_output contains the matrices and regions used to convert between the global coordinate system and the output physical pixels coordinate system
<pq>
you'd set your panel native resolution in the video mode, and hack weston_output members to configure the necessary scaling
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
<pq>
Net147, I would probably start with hacking weston_output_update_matrix() and weston_output_transform_scale_init(), they seem the most relevant
<pq>
current_mode is the video mode resolution in hardware, so your panel native resolution with non-square pixels
Cyrinux9474 has joined #wayland
<pq>
output->width,height are the logical output size in global coordinate system in square pixels
<pq>
and matrix and inverse_matrix are the conversions between the two
<pq>
getting all those set might be enough
<Net147>
pq, okay thanks for the help. I will try it tomorrow.
<kennylevinsen>
or: just look at the display at a slight angle to compensate
andyrtr_ has joined #wayland
andyrtr- has joined #wayland
nerdopolis has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr has joined #wayland
andyrtr_ has quit [Ping timeout: 480 seconds]
andyrtr_ has joined #wayland
andyrtr- has quit [Ping timeout: 480 seconds]
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
<jadahl>
d_ed[m]: fancy compositor handover demonstration
<kennylevinsen>
I was not super excited for crash recoveryg but handover is genuinely cool
<d_ed[m]>
Thanks!
<kennylevinsen>
d_ed[m]: how does the reconnect logic distinguish between compositor gone due to exit and compositor gone due to crash?
<MrCooper>
gone due to exit means display socket is gone as well?
<d_ed[m]>
that's right
<d_ed[m]>
the handoff demo is ever so slightly "faked" to not have that check
<kennylevinsen>
deception?!
<kennylevinsen>
But I guess that makes sense. Not sure how I feel about a "wayland socket manager" parent, but neat regardless.
cstub has joined #wayland
Zeroine has quit []
Zeroine has joined #wayland
cstub has quit []
rasterman has quit [Quit: Gettin' stinky!]
andyrtr_ has joined #wayland
andyrtr has quit [Ping timeout: 480 seconds]
andyrtr_ is now known as andyrtr
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
andyrtr_ has joined #wayland
<orowith2os[m]>
daniels: re the idea of a client tolerating higher latency, was there some frame timing work that would address that?
<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
<orowith2os[m]>
I forgot that was a possibility
andyrtr has quit [Ping timeout: 480 seconds]
rv1sr has quit []
andyrtr has joined #wayland
<orowith2os[m]>
So stating that a presentation would get displayed with less latency optimizations would work too
<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)
andyrtr_ has quit [Ping timeout: 480 seconds]
iomari891 has quit [Remote host closed the connection]
iomari891 has joined #wayland
cmichael has quit [Quit: Leaving]
iomari891 has quit [Ping timeout: 480 seconds]
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
cstub has joined #wayland
iomari891 has joined #wayland
tent405 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
cstub has quit []
tzimmermann has quit [Quit: Leaving]
nerdopolis has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
junaid has joined #wayland
Moprius has joined #wayland
nerdopolis has joined #wayland
cstub has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
kts has joined #wayland
mblenc has joined #wayland
junaid has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
rv1sr has quit []
rasterman has joined #wayland
jkl has quit [Quit: Gone.]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Dami_Lu has quit [Ping timeout: 480 seconds]
sima has quit [Ping timeout: 480 seconds]
Dami_Lu has joined #wayland
mblenc_ has joined #wayland
mblenc has quit [Quit: Quit]
cstub has quit []
mblenc_ has quit []
mblenc has joined #wayland
mblenc1 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
carlos_ has quit [Remote host closed the connection]