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
zebrag has joined #wayland
slattann has quit [Quit: Leaving.]
maxzor has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
maxzor has joined #wayland
zebrag has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
dundidit has quit [Remote host closed the connection]
cool110_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
Arnavion has quit [Quit: Arnavion]
Arnavion has joined #wayland
soreau has quit [Read error: Connection reset by peer]
<zzag>
in other words, things such as subpixel antialiasing is a no-no thing
ahartmetz has joined #wayland
* kennylevinsen
thinks subpixel antialiasing is always a no-no thing, but that's a whole other discussion
<zzag>
emersion: aha, so the approach to implement fractional scaling in the MR matches what I did in https://invent.kde.org/plasma/kwin/-/issues/86#note_419741 (I hardcoded the scale factor to get a poc asap though :D). the protocol allows to get the scale factor with fractional part, after that, use wp_viewporter
<emersion>
yup
<zzag>
kennylevinsen: well, it's still a thing with lo-dpi monitors unfortunately
<kennylevinsen>
sway has pixel grid snapping - would be fun to see if Qt behavior is prettier with that
MajorBiscuit has joined #wayland
bittin has joined #wayland
<zzag>
kennylevinsen: interesting.. does sway move the surface until it snaps to the pixel grid? or does it do something fancier? how does sway ensure that the linear or the nn filter doesn't mess up fonts?
<kennylevinsen>
when rendering a texture to a particular output, coordinates are just rounded to nearest physical pixel. A main quirk right now is that the rounding ends up position-dependent, but that is solveable.
maxzor has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
mvlad has quit [Quit: Leaving]
mvlad has joined #wayland
<kennylevinsen>
s/texture/surface/
lxsameer has joined #wayland
<kennylevinsen>
as for scaling filters messing things up, I don't think we do anything in particular. Just like with how scale 1 works, we just rely on nothing happening when pixels in the surface buffer lines up perfectly.
d_ed has joined #wayland
manuel__ has joined #wayland
Major_Biscuit has joined #wayland
MajorBiscuit has quit [Ping timeout: 480 seconds]
<zzag>
yeah my main concern is that rounding coordinates may break one-to-one mapping and the min/mag filter will start messing fonts up
manuel1985 has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
<d_ed>
Apparently my replies haven't been getting through :/ Sorry for seeming like I've been ignoring you emersion!
<emersion>
ah! a classic
<emersion>
no worries :)
<kennylevinsen>
something something sasl
<d_ed>
It fails so silently
<kennylevinsen>
yeah >:|
testg784578543 has joined #wayland
<kennylevinsen>
I'm still using #mesonbuild as a canary for that :P
<d_ed>
I'd rather have this viewport technique than nothing, and the fact that it works for SDL already is positive. Ultimately we need experiences from people changing the big toolkits and then looking for the edge cases where it fails rather than examples where it works.
<d_ed>
Vlad and I have been working on things - we can complete our Qt implementation Vlad mentioned
<d_ed>
I do think if we go down this path over time we'll go down the route of having both damage and damage_buffer in logical and device pixels respectively but for everything else
<emersion>
(to be clear it's also on the matrix bridge -- OFTC correctly sends ERR_CANNOTSENDTOCHAN, matrix could handle it a lot better than silently dropping it)
<pq>
well, all widget layouting on a surface in an app should happen logical (surface-local) coordinates anyway
<pq>
*happen on
notmart has joined #wayland
<dnkl>
I assume a run-time scale change will result in both a configure() (resize) event, and a preferred_scale() event? It would be nice if they were synchronized in some way, so that the client doesn't have to submit two frames before getting the right combo of buffer size and viewport settings
<d_ed>
With the current wayland approach which the viewport proposal doubles down on there shouldn't be a resize event as the logical geometry stays (roughly) the same
<jadahl>
it's the hint that should be grouped with xdg_surface.configure. the surface state is atomic already
<jadahl>
so either 'wl_surface.configure' (as discussed in the wl_surface.(buffer_)scale MR), or some wording allowing xdg_surface.configure docs to be responsible for grouping both wl_surface.(buffer_)scale and wp_fractional_scaling.fractional_scale or what it now was called
<kennylevinsen>
(right now it's preferred_scale, but it's my intention to align the wording and naming with wl_surface.scale)
<pq>
emersion, swick, I haven't yet read the latest comments, but do you think you can find a middle-ground on the libdisplay-info API design, or should I type up a third proposal?
MajorBiscuit has quit [Ping timeout: 480 seconds]
kchibisov has quit [Read error: Connection reset by peer]
<emersion>
pq, i'm not sure. if you're not happy with either, maybe we need a third one.
___nick___ has joined #wayland
nerdopolis has joined #wayland
<swick>
pq: well, I'm not really married to the design in my proposal but the one big thing I want in the low level API is to retain all information required to go from blob to IR, modify the IR, and then go to a blob again
<swick>
I'm aware that it's a bit more than just being a library to get the information you want out of the EDID but if that's literally all you want all the existing compositor EDID parsing code is good enough
<pq>
well, that's something to be discussed in gitlab
<swick>
we're in this mess because other EDID parsing stuff just throws away all the information it parses after printing it and now what you want to do is retain just as much information which is required to answer some questions a compositor is interested in and throw away everything else
<pq>
if I wanted such an IR, I might go with JSON - lots of ready-made tools to process JSON
<daniels>
I'm not immediately sure there is a meaningful IR which lets you round-trip from blob to blob
<swick>
then someone comes along and wants to do something which requires the information we just threw away and starts libdisplayinfo2
<swick>
and I have a few tools in mind which would require that information
<swick>
pq: sure, don't really care much about it, might be JSON, YAML or XML
<pq>
we don't throw anything away, the cost of keeping the original blob is less than keeping any kind of IR representing it
<pq>
swick, right, but using JSON as input to the high-level API implementation seems like a detour
<swick>
daniels: well, they have a format; it's not arbitrary blobs (except that there might be data which we don't understand yet and just has to be kept around)
<swick>
pq: I'm not saying we should use JSON there at all
<swick>
and with IR I don't mean JSON or anything like it but the in memory interal representation of the parsed EDID
<pq>
swick, but in that case the discussion of an IR is irrelevant - you add JSON output at any time
<pq>
*can add
<swick>
just that it should be possible to go from that interal representation to JSON for example and then from a modified JSON back to the IR
<swick>
pq: this is not just about getting output in JSON but being able to have a complete roundtrip from a blob to JSON which can be modified back to a blob
<pq>
I'm not sure such an IR is even useful... the original blob is tiny compared to any data structure it might be translated into. The low-level API might just read from the original blob.
<pq>
lossless roundtrip, sure, but I don't see how that related to the low-level API that should be used for implementing the high-level API.
<swick>
I don't want to have a function in the library which dumps a JSON representation and one which takes in a JSON representation but being able to use the low level API to build a tool which dumps the JSON and builds the IR from a JSON representation
<pq>
why?
<pq>
why use the low-level API specifically for that?
<pq>
it might make more sense to start with the high-level API, and later see what falls out as a low-level API, when opinionated code is restricted into the high-level API implementation.
<swick>
if we do that we'll be throwing away all the strucurual information because that's not required for the high level querying API
<pq>
we can keep low-level API private until it fills all your goals as well, in addition to allowing implementing the high-level API.
<pq>
err, yeah, you definitely would not use high-level API as a basis for serialization
<emersion>
doing the high-level API first is backwards
<swick>
and we know exactly what we want there
<swick>
so no surprises really
<pq>
The high-level API is the foremost goal. The only reason the low-level API ever came up was that people were concerned that the high-level API might have bad opinions.
<pq>
The reason I want to go high-level API first, because I believe it is the fastest way to get libdisplay-info into use.
<pq>
I personally have no use at all for the low-level API.
<pq>
I worry that it will take considerably longer if the low-level API must be stable before libdisplay-info can be used at all.
<pq>
I guess there would be no point in me trying to type up an API proposal, since our needs are so different.
<pq>
I'll continue reviewing both of your API proposals, but I cannot decide which one to take.
<pq>
swick, I have no fundamental opposition to your plans, just that I think it will take a lot more effort until anything is usable for me. Effort that I cannot help with.
<emersion>
i'm perfectly fine with dropping my proposal fwiw
shankaru has quit [Quit: Leaving.]
zebrag has joined #wayland
radu242 has joined #wayland
radu242 has quit []
shankaru has joined #wayland
remanifest has quit [Ping timeout: 480 seconds]
shashank_s has joined #wayland
agd5f has quit [Remote host closed the connection]
pounce| has joined #wayland
<pq>
I have some Weston color stuff to review before I can get back to libdisplay-info.
agd5f has joined #wayland
anarsoul has quit [Read error: Connection reset by peer]