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
danvet has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Ping timeout: 480 seconds]
paulk-bis has joined #wayland
bodicceaII has quit [Remote host closed the connection]
nobiz has quit [Remote host closed the connection]
Fxzxmic has joined #wayland
Fxzxmic has quit []
Fxzxmic has joined #wayland
<pq>
emersion, re: overscan; I think it comes from the older CRT having round corners and curved edges, and overscan making sure all the phosphor lights up properly, clipping image edges out in the process. :-)
kts has quit [Quit: Konversation terminated!]
<emersion>
aha, got these mixed up
<pq>
how wonderful that we still need to care about these things
<emersion>
cute, another CRT explanation for historical gfx stuff
<emersion>
yeah, really glad we have TVs with the latest and greatest technology 2023 has to offer
<pq>
also, since it was known that receiver CRT will clip, the broadcast has some cruft at the edges that then got clipped.
<emersion>
ok, so overscan is when clipping happens, and underscan is when there is letterboxing
<emersion>
(from a user PoV)
<pq>
meaning that also flat planels needed to clip as well -> overscan by default in TVs
<emersion>
oh, that's why
<kennylevinsen>
overscan by default makes me so very upset
<emersion>
i wonder if HDMI content type helps
<emersion>
ie, if I set HDMI content type, will it fix most TVs
<vsyrjala>
iirc no
<pq>
I believe HDMI has explicit under/overscan messages
<pq>
do TV's actually listen to those? ha ha...
<vsyrjala>
i don't recall if you can tell it to do anything. iirc it can tell you whether it indends to overscan vs. undescan for ce vs. it modes separately of course
<pq>
some do, some don't, and so we need a workaround
<emersion>
how does the source know how to set the margins correctly?
<emersion>
some EDID thing?
<emersion>
(can't remember of any)
<pq>
vsyrjala, oh gosh, it was a message in the wrong direction
<emersion>
i remember the user configuration UIs to setup margins though
<emersion>
ah, ok, so some vague CTA stuff may help
<vsyrjala>
hmm. there is under/overscan stuff in the avi infoframe
<emersion>
but we don't know whether we picked CE or IT…
<pq>
yeah, console games often(?) have margin setup UI
<emersion>
vsyrjala: separate from the bars stuff?
<swick[m]>
we really need a bit more info on modes for underscan, overscan and color range
<swick[m]>
or we just figure it out from the EDID and then compare the modes with the KMS modes
<vsyrjala>
emersion: yeah, and apparently we always set it for underscan. but i'm pretty sure many tvs still overscan
<emersion>
vsyrjala: we = drm core or i915, out of curiosity?
<emersion>
since we set it, some TVs might obey and some might not, so margins really need to be user-configured
<vsyrjala>
looks like vcdb allows the sink to declare what kinds of scan it supports. separately for different kinds of modes of course :/
<vsyrjala>
iirc i once saw some recommendation document for braodcast tv subtitle/etc placement. can't recall the specific numbers
<emersion>
hm right, because you can also place "unimportant" details in the image area which will be potentially overscanned
<emersion>
which is impossible with the margins KMS props btw
<zamundaaa[m]>
<emersion> "ok, so overscan is when clipping..." <- At least the overscan and underscan drm properties do the same thing afaik - they both pad the image on the borders
<emersion>
(i wish the margins were signalling only, and wouldn't actually do anything to the buffers…)
<vsyrjala>
dunno if anything uses the avi bars info tbh. also dp has no such thing afaik
<emersion>
the overscan and underscan props are not standard afaik
<emersion>
vsyrjala: ah, good to know
<zamundaaa[m]>
yes, they're not standard, but we support them in KWin
<zamundaaa[m]>
I do have one question on that topic... does this possibly affect DisplayPort at all, or is it only HDMI and old connectors like VGA?
<emersion>
ville has a branch with DP support for margins props
<vsyrjala>
not sure there are any native dp monitors that overscan. but dp->hdmi converters are certainly a thing
<emersion>
i haven't seen it on VGA
<emersion>
only HDMI and TVout
<zamundaaa[m]>
vsyrjala: We can detect those converts with the subconnector property though, right?
<vsyrjala>
they look like normal dp
<vsyrjala>
don't think we have any subconnector stuff hooked up for that
<emersion>
I think we do?
<emersion>
at least I've seen subconnector=HDMI on DP
<emersion>
the other intern next to me back when I was at Intel implemented it :P
<vsyrjala>
hmm. yes, apparently we do
<vsyrjala>
totally forgot that landed
<vsyrjala>
doesn't seem super robust though. my type-c -> hdmi dongle says 'Native'
Dami_Lu has joined #wayland
<emersion>
ah, sad
eroc1990 has quit [Ping timeout: 480 seconds]
<emersion>
maybe the interface type in the EDID could be more reliable, if set
<emersion>
or is this what the kernel uses?
<vsyrjala>
looks like it currently uses just the dpcd downstream port info
<vsyrjala>
i did tweak some of other dp->hdmi stuff to also check the edid. but that still wouldn't help here since this dongle apparently doesn't claim to be a branch device at all
<emersion>
rip
eroc1990 has joined #wayland
<zamundaaa[m]>
I guess we'll keep on showing the setting for all connector types that support it then... except maybe eDP, it really shouldn't need it
<zamundaaa[m]>
I hope
<vsyrjala>
well, you might want to tweak the edp output size to get eg. 2x integer scaling or something like that
eroc1990 has quit []
eroc1990 has joined #wayland
<zamundaaa[m]>
I'm not sure what you're referring to. What does over/underscan have to do with integer scaling?
<vsyrjala>
you could use the margins for other things than overscan compensation
<emersion>
i'm not sure i'm following…
Major_Biscuit has quit [Ping timeout: 480 seconds]
<vsyrjala>
say you have an emulator rendering at 320x200, you set the mode to match that, set scaling mode=fullscreem, and configure the margins to get an exact integer multiple upscale factor
Major_Biscuit has joined #wayland
<pq>
would that also work on a HDMI monitor that uses the infoframe bar data?
<vsyrjala>
for external connectors the panel will be driven with the mode the user passed in, so no
<pq>
ah
<pq>
"scaling mode" is not infoframe data?
<zamundaaa[m]>
vsyrjala: I'm only talking about hiding the setting from the user in our GUI, where we just give them a 0-100% overscan spinbox
Fxzxmic has quit [Ping timeout: 480 seconds]
<vsyrjala>
pq: no. it just specifies how we set up the scaler
<zamundaaa[m]>
That sounds like an interesting hack though, one that I hopefully never need to implement
kts has joined #wayland
<vsyrjala>
i have occasionally pondered about exposing a 'fixed mode' property for all connector. would allow the same kind of scaler usage for external connectors that you get with internal ones atm
<pq>
use of the scaler inside an external monitor?
<vsyrjala>
scaler inside the gpu
<pq>
display controller?
<vsyrjala>
yes. right now with external monitors the monitor alwasy does the scaling
<pq>
oh, right, to avoid monitor's scaler
<pq>
but then, userspace can simply use the external monitor's native mode, and set up KMS scaling itself
<vsyrjala>
if you have scalable planes
<pq>
by plane props
<pq>
is it common for hardware to have a scaler in/after CRTC but not on planes?
Moprius has joined #wayland
<vsyrjala>
older intel hw was like that. well, there was usually one scalable sprite plane, primary/cursor could not be scaled
<vsyrjala>
and current intel hw has usually two scalers per crtc. each one can scale one plane or the whole crtc
MajorBiscuit has joined #wayland
<vsyrjala>
oh, and cursor still can't be scaled on its onw. only as part of the whole crtc
Moprius has quit []
Major_Biscuit has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
kts has joined #wayland
<vsyrjala>
iirc there was some other proposal for defining the crtc viewport size independent of the mode via separate properties. but i think reconciling that with the way edp/lvds/etc. works currently would tricky