ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<robclark>
imirkin: some of the tools have additional dependencies like lua
<imirkin>
robclark: don't i know it...
<imirkin>
see MR that was just sent :)
<robclark>
oh.. I guess you figured that out
<robclark>
just getting caught up on scrollback
<robclark>
mareko: I think difference is different drivers call them different things
co1umbarius has quit [Ping timeout: 480 seconds]
tarceri_ has quit [Read error: Connection reset by peer]
tarceri_ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
tarceri_ has quit [Remote host closed the connection]
tarceri_ has joined #dri-devel
angular_mike____ has quit [Read error: Connection reset by peer]
ezequielg has quit [Read error: Connection reset by peer]
cengiz_io has quit [Read error: Connection reset by peer]
ezequielg has joined #dri-devel
markyacoub__ has joined #dri-devel
cengiz_io has joined #dri-devel
angular_mike_____ has joined #dri-devel
markyacoub_ has quit [Ping timeout: 480 seconds]
tarceri_ has quit [Remote host closed the connection]
tarceri_ has joined #dri-devel
agd5f has joined #dri-devel
lemonzest has joined #dri-devel
Company has quit [Quit: Leaving]
tarceri_ has quit [Remote host closed the connection]
tarceri_ has joined #dri-devel
Duke`` has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
thellstrom1 has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
tarceri_ has quit [Remote host closed the connection]
tarceri_ has joined #dri-devel
itoral has joined #dri-devel
pnowack has joined #dri-devel
fxkamd has quit []
kmn has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<mareko>
robclark: are you telling me that both nvidia and qualcomm have a scalar processor that works alongside a SIMD?
adjtm is now known as Guest3991
adjtm has joined #dri-devel
Guest3991 has quit [Remote host closed the connection]
thellstrom1 has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
unsolo has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
mlankhorst has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
f11f13 has quit [Remote host closed the connection]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
jkrzyszt has joined #dri-devel
thellstrom1 has quit []
thellstrom has joined #dri-devel
danvet has joined #dri-devel
<Newbyte>
device=all also implies device=dri, right?
pjakobsson has quit [Remote host closed the connection]
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
<MrCooper>
Newbyte: -ENOCONTEXT
<Newbyte>
MrCooper: sorry, wrong channel. thanks for the ping
unsolo has joined #dri-devel
rgallaispou has joined #dri-devel
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
rasterman has joined #dri-devel
gawin has joined #dri-devel
Hi-Angel has joined #dri-devel
Lucretia has joined #dri-devel
<cwabbott>
mareko: qualcomm has scalar registers but no scalar ALU, instead you write to the scalar registers from a vector ALU while only one thread is active (and there's a special branch-on-first-active-lane instruction)
<cwabbott>
so, they're not really written much because there's a penalty of a branch instruction, and exec mask/descriptor address arithmetic is mostly done implicitly so most of the uses AMD has for the scalar ALU are handled via other special-purpose things
<cwabbott>
the only real use of them is read-only scalar things (like, say, workgroup id) and Vulkan subgroup ops that return something scalar (e.g. readfirstlane is implemented as branch-on-first-lane + write to scalar register)
pcercuei has joined #dri-devel
unsolo_ has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
thellstrom has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
pendingchaos has quit [Read error: No route to host]
pendingchaos has joined #dri-devel
adjtm has quit [Remote host closed the connection]
elongbug has joined #dri-devel
adjtm has joined #dri-devel
unsolo has joined #dri-devel
unsolo_ has quit [Ping timeout: 480 seconds]
hikiko_ has quit []
hikiko has joined #dri-devel
<hikiko>
hi, I am trying to debug a drm-tip kernel on my laptop through usb to serial. I've loaded all the drivers (for usb to serial, the converter's etc) in the kernel (=y not as modules), set the same bauds in pc and laptop (my pc has a serial port), and I am able to connect with gdb and minicom but I can't start kgdb (I am using the correct boot options, and I've enabled sysrq). I am suspecting that the problem is that when I examine a tty serial
<hikiko>
driver eg 8250 I see two more callbacks: poll_get_char and poll_pull_char that are missing from my usb2serial converter's driver. Thing is that I grepped for them in all usb/serial drivers and none of them implements them. Has anyone managed to debug the laptop's driver with usb to serial?
<hikiko>
the error I see in my desktop computer (has "real" serial) is: Remote replied unexpectedly to 'vMustReplyEmpty': timeout
<hikiko>
I can't tell if the problem is that I can't poll get/put char from the usb2serial driver (kgdb seems to require that) or something else
<hikiko>
and I am not sure if it's possible that all usb2serial drivers lack those calls
<hikiko>
maybe I didn't understand something and the error is irrelevant ?
Company has joined #dri-devel
thelounge5837 is now known as alatiera
unsolo has quit [Ping timeout: 480 seconds]
vivijim has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
itoral_ has quit [Remote host closed the connection]
unsolo has joined #dri-devel
fxkamd has joined #dri-devel
mclasen has joined #dri-devel
<Company>
pq: btw, re the "will it be merged" question, I think Wayland compositors should get *something* allowing color management going real soon now
<Company>
because the application space - GTK and browsers in particular - is working on color management and if Wayland doesn't have some way of making it work, it'll just cause sadness
<pq>
Company, I have often wanted to talk to you, but you have left IRC by then. How can we chat more reliably?
<Company>
I'm pretty much always here when I'm not asleep
<pq>
Company, many times when I wanted to reply to you, you are not on this channel.
X-Scale` has joined #dri-devel
<Company>
maybe our times just don't match - or you were just unlucky
<pq>
yup, so what we do?
<pq>
what can we do?
<Company>
figure out at what times we are online probably
<Company>
I'm in Europe but usually not awake before lunch, but usually online until late at night - like 3 or so
<pq>
Company, my estimate was based on who currently work in Wayland upstream on the CM&HDR protocol. Help would be nice to get the protocol into shape sooner.
<Company>
I don't think I want a protocol that's "in shape", I'd rather have some initial prototype with very limited features
<pq>
Company, I'm available roughly 7-14 UTC.
camus1 has joined #dri-devel
<Company>
so that all the toolkits and compositors can figure out if they can make that work
<pq>
Company, I that case sorry. Go wild,
<pq>
or, just use the current one
<Company>
and then we can improve on that and figure out what's missing
camus has quit [Ping timeout: 480 seconds]
<pq>
The current draft has pretty much everything I think. All the big items are there, and the big design.
<pq>
The things that will still change are "minor": rearranging interfaces, adding details, and so on.
X-Scale has quit [Ping timeout: 480 seconds]
<Company>
I have no idea what jadahl's plans are with mutter and I don't even know who is working on that in kwin
<Company>
or wlroots
<pq>
I'm pretty sure that if you make client toolkit or server side designs based on the current CM&HDR protocol draft, you will be on a pretty good foundation.
<Company>
pq: my (probably ambitious) goal for the March 2022 release - so Gnome 42 - is to be able to see a HDR photo on a display-p3 monitor without it being constrained to srgb
<pq>
we're still three implementations short from landing it in wayland-protocols, and by the time those implementations appear, I hope we had enough time to sort out all the currently known breaking changes to the protocol.
<Company>
and currently the bottleneck to make that happen is compositors, because no compositor supports anything but srgb
<Company>
and the other thing I worry about is the "some way to test" issue
<pq>
Company, you do know about the wayland-protocols governance rules that say when something can be merged, right?
<Company>
not really
<Company>
because that was never really a concern - GTK implemented/implements the extensions that people deem useful
<Company>
we've had copy/pasted custom hacked together protocols in GTK
<Company>
we've supported 3+ different versions of what ended up being xdg_shell, too
<pq>
yeah, so that's what you get to do: take the draft and rename everything so it won't conflict. I have intended to do the same with Weston.
<Company>
anyway, "some way to test"
<Company>
when people develop code for new features, they want to test them
<pq>
yeah, that's what I've been working on for the whole year
<jadahl>
Company: any CM in GNOME is not feasable until the some first revision of the protocol upstream is ready
<Company>
so when browser hackers want to implement support for colorspaces, they'll use whatever desktop supports that
<jadahl>
the alternative is "gtk_shell" like approach, but I don't think it's a good idea here
<pq>
jadahl, chicken-egg
<Company>
jadahl: i'm mainly wondering about CM inside the shell, ie clutter + cogl
<jadahl>
pq: I mean released, not implemented
<pq>
jadahl, ??
<jadahl>
there are work done towards it
<jadahl>
pq: CM in GNOME 42 would require the protocol to have a version in w-p
<jadahl>
I'm not talking about starting to implement it, i'm talking about it being part of a release
<pq>
yeah, and that cannot happen without three accepted implementations
<pq>
release of what?
<jadahl>
GNOME
<jadahl>
Company was talking about CM in GNOME 42
<pq>
oh, I thought wayland-protocols
<Company>
wait, how are we going to get 3 implementations if no implementation implements it before we have 3 implementations?
<pq>
jadahl, how do you see the roadmap for gnome? I still don't understand "released and not implemented".
<pq>
Company, in practise by copying the draft protocol into a compositor project and renaming every single interface to avoid conflicts. Then test and develop with that.
<jadahl>
release is when we have tarballs that'll be packaged by distributions etc. if we want color management in such a release that isn't a "gtk_color_manager" copy, w-p needs to have it first
<jadahl>
and i'm not convinced we want a "gtk_color_manager"
<Company>
I don't want gtk_color_manager either, but I think we can't avoid that
<Company>
and the good thing is that we can easily remove it, because applications keep working fine without it - or if compositor and app can't agree on the version
<Company>
they'll be looking sad, but they'll still work
<Company>
it's not like with xdg_shell where windows or popups are unusable
<Company>
the hard parts will be getting it right for the complex use cases - ie configuration with colorimeters in movie studios and those things
<Company>
or making sure fullscreen switch the client to the monitor's icc profile
<pq>
I've been spending all my available time in getting Weston towards an implementation because I want to get to testing, which means I have not worked on the protocol itself.
<Company>
I would be fine with a Weston or mutter for testing and a protocol that just says "turn on color management and hand me the icc profile"
<Company>
basically the way X11 does CM
<Company>
jsut so I have a way to tesst the whole pipeline
<pq>
you don't need any wayland extension to do the X11 kind of CM
<Company>
well... - I'd need to make all the other apps look crappy
<pq>
all the work I've been doing on Weston has been aiming to be able to "turn on CM", and none of that has involved any protocol yet, as you can see from the Weston CM&HDR roadmap.
<Company>
I need something that turns on CM for the monitor
<Company>
yeah
<pq>
well, yeah, "other apps" do look crappy in the X11 kind of CM. That's how it is.
<Company>
and all I've been doing is figuring out API and refactoring code for the toolkit, so that I can make CM happen when it appears
<Company>
what's really missing is some dumb way to test that it actually works
<pq>
headless testing
<Company>
right - theory and practice
<pq>
yes, we've been over this before.
Bhawan has joined #dri-devel
<pq>
I don't understand what you want. You want manual visual testing on a real monitor, but I don't understand what you think you are missing from that.
<Company>
I'm missing a compositor that implements some protocol that allows me to do CM really
<Company>
in some basic form
<Company>
(also, I'm missing a monitor that does CM for now, but I'm working on that)
<pq>
what do you mean by "basic form"?
<pq>
monitors don't do CM
<pq>
what do you mean?
<pq>
Is it about setting an actual HDR video mode without the compositor compensating for anything? But then all "other apps" will look like hell. If the compositor needs to do something to "other apps", then there is nothing "basic" in it anymore.
<Company>
I'm missing a monitor with a wide gamut, a hdr montior, whatever people call it when it's not srgb
<pq>
ok.
<pq>
Wide gamut can still be not HDR, but HDR tends to include wide gamut.
<pq>
none of that is "doing CM"
<Company>
yes, I never know which term to use that includes all those things
<pq>
right, terminology is one of the biggest obstacles
<Company>
that are required to make an image appear to look great to some user looking at their screen
<pq>
I've thought of putting up a glossary in the color-and-hdr doc repo
<pq>
that's CM, and it does not happen in a monitor
<Company>
it requires a monitor that can support it
<pq>
No, you can do CM without any visuals.
<pq>
e.g. transcode a video
<Company>
right, of course
<Company>
fwiw, I don't know how helpful a glossary is, because people mean different things for the same terms depending on what group they learned the terms in
<pq>
I think I've been working on exactly what you want for the past year, to be able to test something on a real monitor, but I guess you're just unhappy it takes time?
<pq>
Company, yeah, that's why I think a glossary will help a lot: people can point to definition of what they mean.
<Company>
I guess it doesn't hurt to have one, but it'll not stop people from being confused
<pq>
nothing will ever stop people from being confused, but we can make learning more efficient
<Company>
pq: "unhappy" is a strong word, I'm just trying to figure out the best way to fix the situation with compositor <=> application interaction wrt color management
<pq>
if we could standardise on color terminology around Wayland compositors, that would be great
<Company>
because that's where I see the bottleneck atm
<Company>
in GTK, I'm mostly trying to follow the terminology of the Web - but the web doesn't even know what they are talking about because they have too many groups working on it
<pq>
Web doesn't have HDR.
<pq>
not really
<jadahl>
pq: a dictionary in your cm docs repo maybe
<pq>
Company, hmm, are you perhaps facing opposition like "who needs CM anyway", and you need to make a point?
<Company>
pq: no, absolutely not
<pq>
That's really good.
<pq>
because even that happens
<Company>
pq: it's more about indifference than opposition
<pq>
oh, same difference I guess
<Company>
"this will take ages to happen anyway, so why think about it now?"
<pq>
ah
<pq>
well, I think a good starting point would be to hack a Wayland compositor to set a HDR video mode on a monitor, and watch people's eyes bleed. :-)
<Company>
and those people are somewhat right: those monitors have been out for a while and nothing has happened apart from people arguing in issues and mailing lists
<Company>
once I have such a monitor, that's exactly what I intend to do ;)
camus has joined #dri-devel
<pq>
I have a hack branch for doing that on Weston.
Lucretia has quit []
<Company>
as I said: my main goal right now is to get eog to show a HDR image in HDR on a HDR monitor while the rest of the desktop looks normal
camus1 has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
<Company>
my goal after that is to make sure people who own HDR monitors can reproduce that with a stock Fedora install (potentially by enabling some experimental features, but without installing extra software)
<pq>
Company, compositor implementation wise, that's very close the full-blown CM&HDR implementation.
<Company>
yes and no - the two things I'm leaving out for now are performance and correctness
<Company>
correctness I'm fine with "looks okay", which long-term is not good enough
<Company>
and performance I'm fine if enabling it switches to a performance similar to llvmpipe, which also isn't good enough
<pq>
you could do that with a tiny custom protocol that just attaches "static HDR metadata" to a wl_surface or whatever. That's trivial to write, just look up e.g. the HDMI spec for what those parameters are.
<pq>
or even no protocol at all, just some gnome-shell extension that allows you to "interpret this window as if HDR"
<Company>
yeah, something like that
<pq>
or make that automatic by app_id
lemonzest has quit [Quit: WeeChat 3.2]
<Company>
it would have the neat side effect that it would be an easy testing playground for both compositor and application implementors
<pq>
sounds like you have a plan :-)
<Company>
hehe
<Company>
now I just need to get people to work on it ;)
<pq>
back to drawing board then :-p
<pq>
however, weren't there quite some efforts to enable HDR on mutter already?
gawin has quit [Ping timeout: 480 seconds]
<pq>
for KMS
<Company>
that's a question for jadahl
<Company>
I'm a toolkit person, my knowledge so far pretty much ends at the Wayland fd
<Company>
pq: are you online on weekends usually?
<pq>
Time to learn then! Should be much easier than trying to make sense of CM&HDR theory.
<pq>
Company, usually I'm not. I'm available on my working hours.
<pq>
off-hours I actually try to stay away from anything related :-)
<Company>
so best time to talk for us is weekdays, 12-14 UTC, got it
<pq>
and DST ends for me next Sunday
* Company
doesn't really have working hours, I work when I feel like it
<Company>
but I usually hang out on irc when I'm at home, so that I can answer questions
<Company>
pq: do you know how Windows and MacOS implement HDR? I mean the APIs they expose to applications?
<pq>
nope
<pq>
or maybe I've seen some, but don't really remember
<pq>
fpr the EDR thing
<pq>
*for
mbrost has joined #dri-devel
gawin has joined #dri-devel
Duke`` has joined #dri-devel
unsolo has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
join_subline has quit [Ping timeout: 480 seconds]
gpoo has joined #dri-devel
join_subline has joined #dri-devel
camus1 has joined #dri-devel
pnowack has quit [Quit: pnowack]
sdutt has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
gawin has joined #dri-devel
pnowack has joined #dri-devel
dongwonk has quit [Remote host closed the connection]
Bhawan has quit [Ping timeout: 480 seconds]
Bhawan has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
dongwonk has joined #dri-devel
X-Scale has joined #dri-devel
unsolo has joined #dri-devel
X-Scale` has quit [Ping timeout: 480 seconds]
fxkamd has quit []
unsolo has quit [Ping timeout: 480 seconds]
lemonzest has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
ybogdano has joined #dri-devel
camus1 has quit [Remote host closed the connection]
iive has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
lemonzest has joined #dri-devel
unsolo has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
gpoo has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
ybogdano has joined #dri-devel
gpoo has joined #dri-devel
<zackr>
danvet: do you have any requirements regarding deprecating ioctls? if something has been broken and unused since 2013 can i perform exorcism on it or do i have to pretend it's definitely awesome and working?
<zackr>
i mean driver specific ioctls here
<danvet>
oh if it's been known broken for years and no one cared, just quietly ditch it
<danvet>
ideally with reference to the commit that broke it and why it's all broken
<danvet>
we've deleted lots of such oopsies in the past, even drm ioctls
<zackr>
ah, great. i know ioctl's can be a touchy subject for some, but in particular vmwgfx has a lot of really old ioctl's (e.g. overlay ioctls) for which our para-virtualized device dropped support years ago
<zackr>
we've been keeping the code in case there are users out there but it's been a noop for years
Bhawan has quit []
mbrost has joined #dri-devel
<zackr>
Is the GETFB/GETFB2 considered mandatory for modeset drivers? i just noticed vmwgfx doesn't implement drm_framebuffer_funcs::create_handle which means that neither getfb or getfb2 ever worked with it
mbrost_ has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
i-garrison has quit []
i-garrison has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
pnowack has quit [Quit: pnowack]
camus has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost_ has quit [Remote host closed the connection]
* dcbaker
is not sure if that shows up as something sane across matrix <-> irc bridge
<imirkin>
it does, thanks
<imirkin>
robclark: --^ do you prefer this?
elongbug has quit [Ping timeout: 480 seconds]
<robclark>
on meson things, I'll defer to dcbaker
<imirkin>
dcbaker: dep_lua = dependency('lua', required: false, version : '>=5.2')
<imirkin>
can that be written as like dependency('lua', '>=5.2') ?
<imirkin>
err
<imirkin>
can that be written as like dependency('lua >=5.2') ?
<dcbaker>
no
danvet has quit [Ping timeout: 480 seconds]
<imirkin>
dcbaker: ok. do you know what precisely the version thing looks for?
<imirkin>
it's in the *.pc file right?
<imirkin>
robclark: do you think it's safe to always do >=5.2 on the version, even for the version-specific lua's? based on my lua54.pc file, should be fine
<dcbaker>
right, in pkg-config `dependency('lua', version : '>= 5)` is equivalent to what autoconf would do with `lua >= 5`, but meson also supports using cmake and that doesn't understand `'lua > X'`
<robclark>
so, IME lua's abi isn't _completely_ stable.. which is I guess why some distros have different pc files
<dcbaker>
s/in/with/
<robclark>
somewhere along the way we added a tiny bit of backwards compat stuff to work with different lua versions
<robclark>
I think we have at least a couple different distro containes in CI, so I guess try it and if CI is happy, we're good?
<imirkin>
the change is that now we require the version to be >=5.2 on the version-specific lua's. which SHOULD work fine, if the .pc file has the Version set
<imirkin>
some huge jerk could make a lua52.pc with version 1.5 or whatever. hopefully not ;)
<robclark>
yeah, I'd assume that should be fine
<imirkin>
thanks
<imirkin>
dcbaker: thanks for the assist!
<dcbaker>
I think I added the version check because some distro just had `lua.pc`, not `luaXY.pc`, IIRC
<dcbaker>
np
* dcbaker
did something with that lua check, but it's been a while
<imirkin>
yeah, lua is weird
<imirkin>
lua packaging is weird, that is
<dcbaker>
lua is a bit weird too, but usefully so
<imirkin>
;)
<robclark>
I'd probably prefer lua somewhat less if it weren't such an easy way to bolt on scripting
<imirkin>
just like to v8 :p
<imirkin>
link*
<robclark>
"just"
<imirkin>
nice small dependency
gouchi has quit [Remote host closed the connection]
pcercuei has quit [Quit: dodo]
ybogdano has joined #dri-devel
gawin has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
<karolherbst>
ahhhh
<karolherbst>
slowly I think writing a new bot for kernel stuff is the way to go :(
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
<dcbaker>
robclark: eruby :)
<robclark>
so I just need to re-write our cmdstream decoder to be javascript in an html page?
<robclark>
:-P
<imirkin>
robclark: i know you're just joking, but i've been playing around with wasm