<pq>
HdkR, yeah, if weston has no output, there is nothing to capture. You could configure a "virtual" output with one of the remote plugins, or just force a real KMS connector on. Or use headless-backend instead of DRM-backend and enable a renderer and get a virtual output you can shoot.
frankbinns has joined #dri-devel
<tomeu>
danvet: the .gitlab-ci dir is quite big atm: 14k lines
<tomeu>
a compromise would be to have the files used only for kernel automated testing in the kernel repo, and those shared with mesa ci in their own (still controlled by a SHA reference as it is now)
rasterman has quit [Quit: Gettin' stinky!]
<pq>
HdkR, I wonder if daniels' "you can look at Weston how to <full VM and own TTY>" meant looking at Weston's CI scripts, not using weston itself.
<pq>
HdkR, Weston CI as a test for Weston's DRM-backend which spins up qemu with a custom kernel in order to own the kernel and everything, and still run in "normal" CI runners.
<pq>
*has a test
<daniels>
eyah
<danvet>
tomeu, 14k is nothing in drm, we have amd headers after all
<danvet>
but yeah if it makes sense to share some stuff with mesa, I guess that's reasonable
<danvet>
also for specific machine farms I guess
<danvet>
tomeu, but stuff like how to build things, or adding more Kconfig really should be in the kernel
<danvet>
so that it can be easily shared across drivers and extended and all that
<tomeu>
ok, I think I like to only have what comes from mesa in the drm-ci repo, will make it easier to keep both in sync
<danvet>
I don't think a proliferation of build testing approaches is a good idea
<tomeu>
agreed
<danvet>
tomeu, the other thing that looks a bit funny is pointing at random repos in personal spaces
<HdkR>
pq: I gave weston a virtual 1920x1080 display. Just can't capture it since my XServer didn't have a display and screenshots don't seem to work with xwayland. Oh well
<danvet>
tomeu, so if you're afraid of push back maybe step one would be a more minimal .gitlab-ci that just does build testing for now and stuff like that?
<danvet>
we could send that out, get linus to merge that topic branch (with the note that we do plan to extend this and that he should scream if it gets out of hand)
<tomeu>
danvet: you mean the tomeu/ stuff in the docs? if so that's just for the example
<danvet>
and then add the other pieces
<danvet>
ah ok maybe got confused by that
<tomeu>
we use the community-wide gfx-ci/ space for deps
<tomeu>
maybe I should have used janedoe instead
<danvet>
tomeu, one benefit of adding stuff later on would be that there's a bit more visibility by sending the patches through dri-devel or so
<danvet>
for the shared bits at least
<danvet>
also I guess we need to get drm repos moved to gitlab finally
tursulin has joined #dri-devel
<tomeu>
I'm not sure we would win much by merging just build jobs, as the Mesa infra just makes it easy to do all that testing
<tomeu>
we would be saving just a few dozen lines of gitlab-ci yaml
thellstrom has joined #dri-devel
<tomeu>
well, I think most of the benefit out of this would come from people having automated testing on their personal repos
thellstrom has quit [Read error: Connection reset by peer]
<tomeu>
after that, driver teams can organize themselves to use MRs to merge into their tree, like the freedreno folks are doing
<tomeu>
and after that, it would be kind of replacing git pull requests with MRs, but that sounds to me quite far off from the community side of things
<pq>
HdkR, yes. If you want to capture using X11, you must run Xwayland in rootful mode manually. I thought you were talking about Weston's screenshooting though, not X11.
thellstrom has joined #dri-devel
<HdkR>
pq: I didn't know that weston itself had screenshot capabilities. Which would solve the issue
<pq>
HdkR, normally you screenshoot in Weston with a hotkey. If you use --debug on the command line, it allows manually running the screenshooter program.
<HdkR>
If that could be programatically fired then that would be useful
<HdkR>
Dang, would need to rebuild then. Ubuntu ships one without that command enabled
<danvet>
tzimmermann, mlankhorst mripard I think airlied asked for a resend since he couldn't find it either
<danvet>
something gone wrong somewhere I guess
<pq>
HdkR, uhh, what? There is no buld option to disable --debug.
<danvet>
or just make a new one
<pq>
*build
<tzimmermann>
danvet, ok. mlankhorst is on duty.
<pq>
HdkR, or you mean ubuntu disables the client program for it? I don't think they can, unless they disable the whole desktop-shell...
<pq>
or patch weston in nonsensical ways
<mripard>
I'll do it tomorrow if he hasn't resent it by now
kts has joined #dri-devel
<HdkR>
pq: oh, I misread the debug message "WARNING: debug protocol has been enabled."
<HdkR>
I can give that a try if I can figure out how to screenshot it
<pq>
HdkR, the real purpose of --debug is to allow weston-debug tool to work, but it also allows arbitrary screenshooting.
<pq>
HdkR, you would manually run weston-screenshooter, and it writed a PNG... somewhere
<HdkR>
`display doesn't support screenshooter` womp womp
<pq>
What's "womp"?
<emersion>
"A multi-emotional word, that means everything yet nothing at the same time. A word of such complexity that holds a high standard of intellectuality."
<HdkR>
lol
<HdkR>
Sad trombone esque
epoll has quit [Ping timeout: 480 seconds]
<pq>
That's odd
<pq>
could it have connected to a wrong Wayland compositor?
<pq>
HdkR, taking a couple steps back, what's your goal?
<HdkR>
It's the only wayland compositor running, the main one is i3wm
<emersion>
i3wm is not a wayland compositor
<HdkR>
Which is why I'm running weston on top of it
<pq>
as I said, daniels' intention was to have you look at Weston's CI scripts, not use Weston
<HdkR>
I'll need to skim those scripts then
<pq>
I have no idea if using Weston would help or hurt, whatever your goal is.
epoll has joined #dri-devel
<pq>
HdkR, I really don't see how you could get "display doesn't support screenshooter" if it's connecting to Weston with desktop-shell.
<pq>
really odd
cef has quit [Quit: Zoom!]
<HdkR>
ah, kiosk-shell doesn't support it
<pq>
yup, intentionally
<pq>
..I might even say
cef has joined #dri-devel
<pq>
do not want people to will the kiosk machine with screenshots :-)
<pq>
*fill
warpme___ has joined #dri-devel
Haaninjo has joined #dri-devel
sravn has joined #dri-devel
rahul_janga has joined #dri-devel
bmodem has joined #dri-devel
pcercuei has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
<danvet>
tzimmermann, javierm so for the glorious future of disabling fbcon
<danvet>
do you have some rough consensus what will stay and what will go already?
<danvet>
like fbdev emulation still needed for some old stuff or not?
<danvet>
also how much of CONFIG_VT will go into userspace?
<tzimmermann>
danvet, i have not looked closer
<danvet>
like just the tty vt stuff, or also the normal kernel log printing
<tzimmermann>
what we need is fbdev emulation for drm, a drm-based log printer and a userspace console
<danvet>
or do we need some config_vt (just with dummy con and nothing else) for backwards compat in the vt switch dance
<tzimmermann>
the fbdev console itself can go away
<danvet>
tzimmermann, yeah but how should the drm log printer interact with the userspace console in normal operations?
<tzimmermann>
i don't know what requirements kgdb has
<danvet>
like at oops time it'll just take over whatever is there
<tzimmermann>
i have not looked yet
<danvet>
I killed kgdb pretty good :-)
<danvet>
but at normal time it's probably cleaner if the userspace console/boot splash takes care of everything
<danvet>
including printing kernel messages, if you're showing boot logs
<danvet>
I guess we could also make a cascade work, if it has to be in the kernel
<danvet>
i.e. if both no drm master and no open fbdev user is around, then drmcon is active
water has joined #dri-devel
water_chika has joined #dri-devel
water_chika has quit []
water has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
jkrzyszt has joined #dri-devel
lynxeye has joined #dri-devel
lemonzest has joined #dri-devel
sergi has joined #dri-devel
<javierm>
danvet: I haven't looked closely either but agree with tzimmermann on what he said
<javierm>
danvet: AFAIU the drm log would only be used for a panic handler
<javierm>
normal interaction could use kmscon (or systemd-console which existed at some point but got removed due never being used)
kts has quit [Quit: Konversation terminated!]
<danvet>
javierm, yeah probably want to resurrect systemd-console for all this
<danvet>
and integrate it better with logging in journald or whatever
<danvet>
so that the "hit key to watch boot logs" stuff still works, but all done in userspace
<javierm>
danvet: agree
<danvet>
tzimmermann, javierm another one is emergency console when root mounting fails from initramfs?
<danvet>
just crossed my mind
Surkow|laptop has quit [Remote host closed the connection]
<javierm>
danvet: but do really need that? That is, if the initramfs failed due being wrong/corrupted/whatever, would a VT even be useful?
<javierm>
danvet: there will be a panic if init isn't found anyways, so the drm log as panic handler would print the logs
kts has joined #dri-devel
<danvet>
javierm, I more mean "couldn't find root fs" or so
<danvet>
iirc initramfs has enough systemd that maybe it works with all userspace console
<javierm>
danvet: yes
Surkow|laptop has joined #dri-devel
kts has quit []
<javierm>
if the problem is only a wrong root= or /dev/disk/by-uuid/foobar not found then a user-space console would still work
<javierm>
assuming you have simpledrm built-in
kts has joined #dri-devel
<javierm>
danvet: so the missing bit I think is "just" a panic handler that uses the DRM client API
<javierm>
that's just the kernel-log drm rendering part so it needs a panic handler on top. Although I needed to investigate if that patch wouldn't be needed anymore and the DRM client API could be used instead
<pq>
I'm curious, will it attempt a modeset into a simple XRGB buffer and disable overlay planes, if the current primary buffer is e.g. YUV and some overlays are up?
<pq>
I'd assume "no" :-)
<javierm>
pq: I would assume no as well, it would just use whatever buffer is provided by the firmware (i.e: just like efifb, vesafb, etc do)
<javierm>
pq: and once a real DRM driver kicks in, probably whatever format was set. That's what fbcon + drm fbdev emulation does now I think?
<Ristovski>
Yesterday my Haswell (and GCN1.0 on the amd side) machine died, which probably dropped the number of "annoying" users (aka ones that can report bugs :P) of such old hardware to a even _lower_ single-digit number
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
kalidows has joined #dri-devel
h0tc0d3 has quit [Remote host closed the connection]
thellstrom has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Quit: fab]
<FLHerne>
I'm still using this IVB laptop as my primary device, but rarely seem to have any problems
kts_ has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
cengiz_io has quit [Ping timeout: 480 seconds]
lemonzest has quit [Remote host closed the connection]
cengiz_io has joined #dri-devel
ivyl has quit [Quit: end of flowers]
rgallaispou has joined #dri-devel
dviola has joined #dri-devel
Duke`` has joined #dri-devel
ivyl has joined #dri-devel
ella-0 has quit []
ella-0 has joined #dri-devel
kalidows has quit [Ping timeout: 480 seconds]
slattann has quit [Quit: Leaving.]
fab has joined #dri-devel
heat has joined #dri-devel
<ccr>
2 Haswell machines here, both in active use :P
<ccr>
no, wait, actually 3. 2 desktop and one laptop.
fab_ has joined #dri-devel
fab_ is now known as Guest2040
fab has quit [Ping timeout: 480 seconds]
<pcercuei>
I'm using haswell… as well
tzimmermann has quit [Quit: Leaving]
frieder has quit [Remote host closed the connection]
khfeng has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand, jenatali: any idea on how to parse this? "OpDecorate %call_i SpecId 4285822057"
<karolherbst>
especially that constant
<karolherbst>
kind of not understanding what the spec is trying to tell me there
<Ristovski>
Ah, my Embedded Controller is dying, this will be fun
lemonzest has joined #dri-devel
thellstrom has joined #dri-devel
<danvet>
javierm, for the panic part we need to draft patch noralf was working on
<danvet>
with all the trylock infrastructure and taking over the biggest currently visible plane
<danvet>
pq, ^^ no modeset in panic, it's pretty much impossible on modern hw
<danvet>
javierm, I guess another issue here is all the drm drivers which don't to fastboot
<danvet>
if you don't have a boot splash or boot console from userspace, then there simply wont be anything enabled
<danvet>
since fbcon takes care of that now
kalidows has joined #dri-devel
<javierm>
danvet: ah, I thought noralf was working on a drmcon. But maybe I'm misremembering
<javierm>
danvet: can you elaborate on the fastboot and boot splash thing? I thought that a kmscon/systemd-consoled/foo would take care of that, what is required for the driver to do?
Haaninjo has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
<danvet>
javierm, yup, that's also the big thread with all the discussions I think
<danvet>
javierm, it's just that between drm taking over and systemd-consoled doing its thing, there's a window where you have nothing
<javierm>
danvet: yeah, added to my read queue
<danvet>
but it kinda exists already, just bigger
<danvet>
since drm drivers also unload the fbdev/fw driver first before they do anything
<danvet>
so fundamentally drmcon is best effort
<javierm>
danvet: yeah, there's a window between fbcon unbind / binds from efifb -> drm driver fb emulation
rkanwal has quit [Quit: rkanwal]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<karolherbst>
"%122 = OpPtrCastToGeneric %_ptr_Generic_v3ulong %__spirv_BuiltInWorkgroupId" the heck
<karolherbst>
how is that even legal
tursulin has quit [Ping timeout: 480 seconds]
kalidows has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
slattann has joined #dri-devel
kts has joined #dri-devel
ella-0_ has joined #dri-devel
kalidows has joined #dri-devel
iive has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
rahul_janga has joined #dri-devel
rahul_janga has quit []
<jekstrand>
karolherbst: That's weird. Is it trying to specialize a function call? IDK how that'd work.
<karolherbst>
na.. it's uchar and I was reading it worng
<karolherbst>
no.. that part is fine
<karolherbst>
something else is bonkers
<karolherbst>
was looking at sycl stuff and hit clc asserts,but the assert was just wrong
<karolherbst>
but they are doing things like this: %122 = OpPtrCastToGeneric %_ptr_Generic_v3ulong %__spirv_BuiltInWorkgroupId
rahul_janga has joined #dri-devel
<karolherbst>
and the builtin is crossworkgroup :(
<karolherbst>
and I have honestly no idea why it is
<jekstrand>
Woof
<karolherbst>
of course nothing in the old CL 2.x spir-v specs are saying this is wrong, it only got fixed for CL 3.0+
<karolherbst>
still trying to figure out why sycl is doing it
<jekstrand>
I mean, I guess we could copy all inputs and builtins to locals at the start of the kernel just in case and then hope copy propagation fixes it.
<jekstrand>
But that's kinda mean
thellstrom has quit [Ping timeout: 480 seconds]
<karolherbst>
or they could just generate valid spirv
<karolherbst>
jekstrand: I figured it out.. if using sycl it's not using function calls for builtins, but just global variables, so all that proper handling isn't happening :(