00:20 anholt: ajax: were you lost in some big-endian formats recently?
00:23 karolherbst: anholt: I was looking into on how to fix this antire big endian format mess
00:24 imirkin: rm -rf bigendian?
00:24 karolherbst:should get back to it next week
00:24 karolherbst: imirkin: yeah......................
00:24 karolherbst: I wish it's that simple :D
00:25 airlied: damn you s390 :-P
00:25 imirkin: there's a guy in #nouveau with unspecified weird issues uploading textures
00:25 airlied: though I'm happy to rm -rf hw endian
00:25 imirkin: (on BE)
00:25 airlied: hw big endian
00:25 imirkin: good thing the NVIDIA GPU is LE ;)
00:25 imirkin: (on a BE CPU)
00:26 anholt: karolherbst: one of the places we're going to find easy bugs is how u_format.csv for packed formats (using Mesa format terminology, i.e. *pN channels where N != 8) has channel setups that should be systematically derived from the left column instead of entered by humans
00:26 karolherbst: anholt: yes, it's completely broken
00:26 karolherbst: this big endian channel order thing is complete nonesense
00:26 imirkin: the thing i hate is that BE stuff tends to be broken in pairs
00:27 imirkin: so when you fix one thing, you have to fix another one
00:27 imirkin: coz it kinda-sorta works as-is
00:27 karolherbst: anholt: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7689 my first approach to get it all into a sane state
00:27 anholt: imirkin: I had to revert a BE fix because llvmpipe mistook an array format for packed or the other way around.
00:27 imirkin: yeah
00:27 karolherbst: anholt: if you have time to think about the problem: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7776
00:28 karolherbst: I want to start with the test data and work my way up
00:28 karolherbst: meaning, having a solid definition how data should look like in memory before fixing up crap
00:28 karolherbst: and making the test pass first
00:28 karolherbst: (which I have locally)
00:30 karolherbst: I'd love if IBM devs would drive fixing this all up though
00:31 karolherbst: or is there anybody else interested in actually fixing it for real?
00:35 imirkin: anholt: btw, do you remember the details of such a fix? that's what we're seeing here ... some kind of wrong packing ... sometimes
00:35 airlied: karolherbst: IBM is driving it, by getting you to do it :-P
00:36 karolherbst: yeah, I guess
00:37 karolherbst: I just wished I'd get more people to think about the issue and the MRs I am opening, but maybe I also needs this one big MR fixing it all in one go
00:37 karolherbst: so we can CI it and be done with it?
00:37 karolherbst: *sigh*
00:38 airlied: it's likely going to a super fix it all MR for llvmpipe and see how badly nv40 BE ends up
00:40 karolherbst: :D
00:40 karolherbst: yeah...
00:40 karolherbst: I think my goal is to make our tests happy and the CTS
00:40 karolherbst: _but_ what I don't know is, if the CTS is even correct for BE
00:40 karolherbst: probably the most annoying bit
00:41 anholt: imirkin: 1886dbfe7362baa221009371434f158b97183164 is the key commit explaining the llvmpipe issue.
00:42 karolherbst: anholt: you know what's broken? 16 bit color depth :p
00:43 anholt: I may have overstated things when I said "the" llvmpipe issue.
00:43 karolherbst: this entire format stuff is just super bonkers
00:43 karolherbst: and makes no sense
00:43 anholt: I would recommend starting from the generated code for u_format_table.c. it's as authoritative as you get.
00:44 karolherbst: this entire "be" channel thing has to get removed otherwise we will never be able to fix BE
00:44 anholt: if someone's doing something different with pixels, they're wrong.
00:44 karolherbst: u_format_table.c is wrong :p
00:44 imirkin: anholt: thanks for the reference
00:44 imirkin: i had seen some of your fixes landing, but didn't realize hey had to be backed out
00:45 karolherbst: seriously. we have to remove this "BE order" thing from the csv
00:46 anholt: I've got some more format code removal that I'm working on finishing off (!6297), but to fix BE I'd really start by making an assert for generating the current "BE order" in the csv from the LE order, then remove the BE order from the table in favor of your generated values.
00:46 anholt: then, once you've got the table fixed, you can look at cleaning up the madness of having BE vs LE channel differences at all
00:47 karolherbst: anholt: no
00:47 karolherbst: changing the order is the wrong approach
00:47 karolherbst: it makes no sense if you think about it for packed formats
00:47 anholt: I absolutely agree!
00:47 karolherbst: ahh, okay
00:47 anholt: I'm saying how you take bites of the elephant.
00:47 karolherbst: mhh, I have it all fixed locally
00:47 karolherbst: at least the unit tests we have inside mesa
00:48 anholt: woo! looks like my csv fix has !6297 fixed finally.
00:48 Kayden: think I have t_rebase_prims fixed so swtnl doesn't die on start > 0 and min_index > 0
00:48 karolherbst: anholt: anyway, I think if you are done with the normal format cleaning up stuff I could probably rebase my stuff on it
00:49 karolherbst: looks like a good cleanup
00:49 Kayden: now I just need to figure out why lineloops are totally broken
00:49 karolherbst: anholt: btw, what's your reason to care about BE? :D
00:50 anholt: karolherbst: because it's more code in the way of me deleting more code.
00:50 imirkin: Kayden: if you need a test on nouveau_vieux, i happen to have one plugged in
00:50 karolherbst: anholt: ahh, fair enough
00:50 karolherbst: anholt: I think you can ignore the BE bits for now as I am planning on removing that anyway :p
00:50 karolherbst: I just need to get it all working
00:51 karolherbst: I had all the CPU based conversion stuff fixed, but llvmpipe was still giving me a few headaches
00:51 Kayden: imirkin: cool! we'll probably want to make sure there aren't regressions from 20.3 to master (or 21.0)...I'll try and let you know when I've got more fixes posted
00:52 anholt: -241kb of gallium driver, woo!
00:52 karolherbst: nice
00:53 karolherbst: airlied: I was thinking if enabling the u_format test thing on CI would be a good intermediate step as long as I don't cause regressions
00:53 anholt: having piglit and khr-gl in mesa ci these days makes this much nicer to work on.
00:53 karolherbst: meaning.. fixing it first, then enabling it and keep it fixed
00:54 karolherbst: but for that I wanted to discuss _how_ the test data should look like first in memory
00:54 karolherbst: hence https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7776
00:54 karolherbst: anholt: ^^
00:54 anholt: agreed, I think I can get you review for that, if you can get the test enabled and passing in that MR
00:54 karolherbst: yeah, okay, I could do that
00:56 Kayden: ah, line loops don't work because we convert them to line strips, then pepp's code just straight up switches the mode to line lists without actually changing any of the data
00:57 Kayden: that's not likely to work :)
00:57 imirkin: strips .... lists ...
00:57 imirkin: it'll 50% work
00:57 imirkin: not as bad as tristrip -> tris
02:20 Kayden: yay, down to 3 regressions on i915 between 20.3 and master
02:28 Kayden: 2 actually :)
02:33 dcbaker: \o/
06:31 mareko: Kayden: it changes line strips to line lists using an index buffer
06:32 mareko: it's a way of combining small draws because VertexID and PrimitiveID are allowed to be undefined with display lists
06:43 pinchartl: danvet: you're right, the mapping isn't fixed
06:44 pinchartl: it's not great :-(
06:44 mareko: I wonder if we should switch to i915g for the next release by default
07:20 Kayden: mareko: sometimes it does, yes
07:20 Kayden: mareko: other times it just leaves the primitives unmodified but changes mode
07:20 Kayden: easy 2 line fix
07:33 mareko: ok
08:51 kusma: could someone with admin privileges delete this branch? It's protected, but the MR that it was created for has been recreated from a fork instead: https://gitlab.freedesktop.org/mesa/mesa/-/tree/1020-u_queue-c-173-7-error-implicit-declaration-of-function-timespec_get-is-invalid-in-c99
09:00 mareko: kusma: done
09:06 Kayden: think I got all the g33 regressions fixed :D
09:06 Kayden: so many bugs in the tnl code
09:07 Kayden: think I found 2 bugs in the new code, and 3 bugs in tnl
09:07 Kayden: tnl trying to handle index buffers...very, very badly
09:12 Kayden: 3/5 were pretty simple, at least
09:18 kusma: mareko: thanks :)
10:25 Vanfanel: pq: I have been thinking about the WaitPageflip loop and I would like to ask you a little question: in https://github.com/vanfanel/SDL/blob/ef050bc0cabc478bf43a83506d43b4d404baaa84/src/video/kmsdrm/SDL_kmsdrmvideo.c#L397, I return if an event arrives on the FD but it's not a POLLIN event. Isn't that just wrong? I mean: I shouldn't be returning if a strange event arrives, but should re-enter the loop
10:25 Vanfanel: and wait for the proper one, right?
10:28 pq: Vanfanel, I suppose, but since you don't tell poll to watch for POLLOUT, it doesn't return POLLOUT.
10:29 pq: you check for HUP and ERR, I don't recall anything else being possible
10:29 pq: so your else branch triggers only on timeout
10:31 pq: check 'man poll' for what you might get
10:31 pq: Vanfanel, poll() returning EINTR you might want to check btw.
10:32 pq: err, returning -1 and errno being EINTR
10:37 Vanfanel: pq: but I do check for negative poll() return values in https://github.com/vanfanel/SDL/blob/ef050bc0cabc478bf43a83506d43b4d404baaa84/src/video/kmsdrm/SDL_kmsdrmvideo.c#L379 , which covers that case, doesn't it?
10:37 pq: Vanfanel, yeah, but do you want to fail or restart the poll, if a signal arrives?
10:38 pq: since you're a library, you might not know what the application uses signals for
10:40 pq: usually one just restarts the syscall so that random signals don't fail the operation unnecessarily
10:44 HdkR: ^ My emulator is likely to break that poll if you don't check for -EINTR
10:51 HdkR: Up until I block the app from ever seeing extraneous signals anyway...
11:03 Vanfanel: HdkR: do you mean your emulator can send events to the FD? if it uses SDL2, it shouldn't care about those things, sorry if I am missing something.
11:04 HdkR: Vanfanel: Signals get sent to the process/thread which can interrupt syscalls. Poll is one of the syscalls that return on interrupt rather than immediately restarting
11:05 HdkR: (Any syscall that blocks on IO can EINTR)
11:06 Vanfanel: HdkR: I don't understand any of that, sorry :( So just for saving your time, what should I do with EINTR on my WaitPageflip() function?
11:07 emersion: you should poll() again
11:07 HdkR: ^
11:07 emersion: int ret = poll(…);
11:07 emersion: if (ret < 0 && errno == EINTR) { continue; }
11:08 emersion: assuming the whole thing is in a loop
11:08 Vanfanel: yes, it is
11:09 HdkR: I personally enjoy when SIGWINCH breaks assumptions. Oops, resized terminal and everything exploded
11:11 Vanfanel: emersion: for other negative values returned by poll(), I shouldn't be back to polling, should I?
11:11 emersion: no, otherwise you might enter a busy loop
11:11 Vanfanel: ok, thanks
11:11 emersion: else if (ret < 0) { perror("poll failed"); break; }
11:20 Vanfanel: emersion: is it a problem if I check against ret instead of errno?
11:21 pq: Vanfanel, when a process receives a signal, if the process is sleeping inside a syscall, the signal may cause the syscall to return with error EINTR. It has nothing to do with the fd you are polling, it's just how signals and syscalls work.
11:21 pq: Vanfanel, ret will be -1 while errno will be EINTR. -1 != EINTR, so yes, it matters.
11:21 Vanfanel: emersion: forget my question... it has no sense :D
11:21 Vanfanel: yes, now I remember. Thanks pq!
11:22 pq: also errno contains garbage if ret != -1, so you must check both
11:22 emersion: Vanfanel: be careful, errno is only guaranteed to be set when poll returns <0
11:22 pq: ^
11:23 emersion: if poll returns >=0, then maybe errno is set to the value of a previous, unrelated error
11:24 emersion: maybe you checked whether a file existed with stat() some time before. then errno will be ENOENT if poll() returns >=0
11:24 emersion: tl;dr only use errno on failure
11:25 Vanfanel: emersion: what I do is check error ONLY when pull() has just returned < 0. I believe that covers it?
11:25 Vanfanel: check errno, I mean
11:25 emersion: yes
11:25 emersion: i'm warning against this kind of code:
11:25 emersion: int ret = poll(…);
11:25 emersion: if (errno == EINTR) { … }
11:26 Vanfanel: ah, no, I am guarding that inside a if (ret < 0)
11:26 zzag: I've noticed that presentation timestamps passed to the page flip handler(drmEventContext.page_flip_handler) are in the future by a couple of hundred microseconds. Is this intentional or is this a bug?
11:26 pq: zzag, it's normal.
11:26 zzag: oh, okay, gotcha
11:26 pq: zzag, some driver do know a little before-hand when it will happen.
11:27 pq: for sure
11:27 zzag: that makes sense
11:27 pq: zzag, as in, the hardware is already programmed so nothing can stop it anymore.
11:29 ccr:sings "don't stop me noooww"
11:29 pq: it's probably also related to when the hardware actually triggers interrupts wrt. to the scanout cycle, it can differ
11:29 pq: beginning vs. middle vs. end of vblank
11:30 pq: while the timestamps returned to userspace have a fixed definition, not driver-dependent
11:34 Vanfanel: emersion: here's how I did it in the end :) https://github.com/vanfanel/SDL/blob/bd3a0749ea6b071f83a0b36b6793aef35f4c6d5f/src/video/kmsdrm/SDL_kmsdrmvideo.c#L384
11:36 Vanfanel: HdkR: since you have a real-world example, can you give me your input on https://github.com/vanfanel/SDL/blob/bd3a0749ea6b071f83a0b36b6793aef35f4c6d5f/src/video/kmsdrm/SDL_kmsdrmvideo.c#L414 ? Should I return there or just go back to polling?
11:47 pq: Vanfanel, why do you have such a hard time with this?
11:49 HdkR: pq: If you're not used to signals interrupting things then it can be hard to understand at first :)
11:49 HdkR: But from looking at that code, it looks like you're handling it correctly now
11:50 pq: but this question wasn't about EINTR anymore
11:50 HdkR: ah, I was getting distracted by a different conversation
11:51 pq: I don't know how SDL is supposed to handle things, so I can't say what is right in this case.
11:51 pq: I can only recommend reading 'man poll' and determining which cases you want to handle and how.
11:51 HdkR: Original code was already infinite waiting so it isn't worse to me :)
11:52 pq: yeah, so rather than returning failure, it should just poll again?
11:53 pq: the branch where poll() returned success but it wasn't POLLIN
11:53 pq: so... just delete the else-branch?
11:54 Vanfanel: pq: that's what I am asking myself right now. I guess going back to polling is a good idea, after all the pageflip event has to come eventually.
11:56 Vanfanel: pq: anyway, if I return there, instead of going back to polling, the following drmModePageFlip() won't be done, and the next frame won't be shown. I prefer to hang on an infinite poll() beacause of a broken driver that doesn't send the event to a pageflip, than missing frames.
11:57 Vanfanel: ...but then again, I don't know if that's just obsessive on my part and a bad idea
11:57 pq: right, and it wouldn't be just missing some frame, it would miss all following frames
11:58 Vanfanel: pq: and after all, it will be easier to diagnose an stuck poll() call. At least I will easily see what's going on.
11:58 pq: "miss a frame" is not a thing, you can either wait or abort
11:59 Vanfanel: pq: well, SDL2 doesn't even take into acount what SwapWindow() returns, so it will try to SwapWindow() again.
12:00 pq: but you still wouldn't try to call drmModePageflip() again, would you?
12:01 Vanfanel: https://hg.libsdl.org/SDL/file/50326832c1f7/src/video/SDL_video.c#l3743
12:01 pq: what I'm saying is, it's fine.
12:02 Vanfanel: pq: as you can see, SDL just asks for a pageflip, it doesn't mind if it's done OK or not
12:02 pq: Wait indefinitely is ok. If you wanted to be more friendly in a failure case, you'd have a timeout that will abort the program, so the user gets his machine back.
12:02 Vanfanel: so it will ask again
12:03 Vanfanel: pq: yep, I implemented the timeout, but then I thought... SDL2 without X11 is a console-like enviroment. I am OK with the hang. Debug has to be done on SSH anyway.
12:05 pq: Vanfanel, no, I mean https://github.com/vanfanel/SDL/blob/bd3a0749ea6b071f83a0b36b6793aef35f4c6d5f/src/video/kmsdrm/SDL_kmsdrmopengles.c#L102
12:05 pq: so you never try to drmModePageflip() again as long as the event does not come, regardless of what the SDL app does
12:07 Vanfanel: pq: there's an small idiomatic barrier here. Are you saying I shoul not do drmModePageFlip() again, or are you saying that, as things are, I am not doing drmModePageFlip() again?
12:07 Vanfanel: *should
12:07 Vanfanel: the barrier is on my side, sorry. It's not you.
12:08 pq: I'm not saying you *should* anything. I'm telling you how your code works right now. ;-) - If I read it right.
12:09 Vanfanel: pq: ok, ok. As things are, if KMSDRM_GLES_SwapWindow() returns FALSE, SDL2 just ignores that, and will call KMSDRM_GLES_SwapWindow() again and again whenever the app asks for a window buffer swap.
12:10 Vanfanel: pq: so, if WaitForPafeflip() fails, it will be called again, and again... because KMSDRM_GLES_SwapWindow() is called even after it fails 1 time.
12:10 pq: exactly, and nothing resets waiting_for_flip
12:11 pq: and nothing asks for another pageflip event either
12:11 pq: meaning that the program is frozen for good
12:12 pq: it just spins but nothing ever updates on screen
12:12 pq: hence, waiting for the event indefinitely is better than failing the wait
12:13 pq: having a timeout and abort would be better than waiting indefinitely, as then the end user might be able to get his machine back if the screen freeze happens
12:14 pq: OTOH, if the app keeps on spinning, the user might be able to quit it blind?
12:15 pq: exiting when you see you cannot make progress would probably be more friendly
12:18 Sumera[m]: danvet, melissawen: I was looking at this patch(https://lore.kernel.org/dri-devel/20200408060503.47709-1-gabrielabittencourt00@gmail.com/) by Gabriela which tried to add virtual hardware module, but I can't find any review comments. Was wondering if anything should have been done differently...
12:24 Vanfanel: pq: since SDL2 takes over the keyboard, the user can't get out of the app from the local keyboard, it has to be killed via ssh.
12:25 Vanfanel: pq: unless the user knows how to exit blindly, but that's not something I want to count on
12:26 emersion: SDL2 doesn't interecept vt-switch keyboard sequences?
12:26 emersion: intercept*
12:26 Vanfanel: ...and that's if I leave the app spinning after a pageflip event missing, which I don't
12:26 Vanfanel: emersion: no, it doesn't
12:27 emersion: maybe it should?
12:27 pq: it should
12:27 pq: it should also correctly take over the VT if it doesn't
12:27 emersion: yeah, switch to graphics mode and all that
12:27 emersion: libseat can help you with that
12:27 pq: Vanfanel, how do SDL apps get keyboard input? Do they use stdin, or do they open /dev/input/...?
12:31 pq: if there is no emergency exit key, then aborting after timeout (with proper VT restoring) seems like a good idea
12:31 pq: needing ssh to get your machine back is a bit of a hassle
12:35 Vanfanel: pq: I have no idea how SDL gets the keyboard input. What function should I look for? I have the sources right here obviously, but I just do KMS/DRM things on them.
12:35 pq: I don't know. There is no one function.
12:36 Vanfanel: pq: maybe an ioctl on something keyboard-related..?
12:36 raket: pq: what about export SDL_INPUT_LINUX_KEEP_KBD=1 somecommand_that_uses_sdl2_kmsdriver
12:36 pq: raket, uh, what does that do?
12:37 pq: Vanfanel, nothing comes to mind... except TTY/VT setup
12:37 pq: Vanfanel, libinput maybe?
12:37 raket: pq: i didn't get keyboard in my sdl2 kms application and with that export line i was able to do a VTY switch
12:37 pq: Vanfanel, there are so many ways to do that.
12:38 pq: raket, that sounds like everything you type in the app will also into the terminal...
12:38 pq: *also go into
12:38 pq: which is really bad
12:39 Vanfanel: pq: yes, if I log thru ssh, key presses in-app get to the console
12:39 pq: like, you think you are typing into a chat, but the same text goes to the shell and gets executed as a command when you press enter -kind of bad
12:39 Vanfanel: pq: exactly, that's a BIG and nasty thing that is happening
12:39 Vanfanel: but I didn't know it could be fixed
12:39 pq: aha, so the VT setup is broken then
12:40 pq: sure it can be fixed: you stop the VT for getting *any* input with the right ioctls
12:40 pq: all display servers do that
12:41 pq: I forget if logind does it for you when you use it, it might
12:41 pq: and now we come to the topic what in weston is called "launchers"
12:41 raket: pq: hm.. i really came here to ask why mesa 20.3.3/nouveau/maxwell (900-series) has weird behavior in quakeworld. just out of the blue i tried running the sdl2 opengl quakeworld binary in the console. without that export the keyboard doesn't work and i also had the same issue you are describe. :-). last time i threw out a question like this someone here in mesa actual fixed a bug in mesa but introduced
12:41 raket: another :-)
12:42 pq: maybe look at libseat
12:42 emersion: https://git.sr.ht/~kennylevinsen/seatd/
12:44 pq: Vanfanel, there are various arcane spells one has to invoke when starting a graphical app doing its own input on a VT. You could study the arcane arts, or you could depend on logind, or just use libseat.
12:44 danvet: Sumera[m], I'm not exactly understanding why patch 1 was done
12:44 danvet: patch 2 still looks roughly correct, but instead of the flag in struct vkms_composer we need it in struct vkms_config
12:44 pq: Vanfanel, you also need the counter spells on clean-up, even if your program is crashing, which is why using a daemon process to do it is common.
12:45 emersion: daemon process = logind or seatd
12:56 danvet: ickle, https://paste.debian.net/1181236/ at the very bottom, good enough "don't do this"?
12:57 ickle: s/directly the importer/by the import/
12:57 ickle: +er
12:57 danvet: or add an even more explicit "you do not own the sglist until @unmap"?
12:58 ickle: "return the same one for multiple calls" is clear
12:59 ickle: Ownership of the sglist is transferred to the caller, and retuned by unmap
12:59 Vanfanel: pq: I am not depending on logind or use another lib, so I guess it will have to be arcane arts. It can't be a lot of code, and it will be packed in a single place...
12:59 danvet: yeah I think adding something like that would be good
12:59 kennylevinsen: pq: ah, that reminds me I that I forgot to post my Weston MR for libseat
12:59 emersion: Vanfanel: why not depend on a lib?
13:00 danvet: https://paste.debian.net/1181237/
13:00 danvet: CI also now happy too
13:00 ickle: s/retuned/returned/
13:00 ickle: reads well
13:00 pq: Vanfanel, I wasn't kidding when I call it "arcane spells".
13:00 Vanfanel: emersion: because I don't want X-less SDL2 to depend on an additional library to be built
13:01 emersion: you depend on libdrm
13:01 kennylevinsen: it's not X-less, it's DRM-full
13:01 emersion: and other libs
13:01 emersion: why does it matter?
13:01 ccr: cup half full?
13:02 danvet: also spelled out scatter list for final polish
13:02 emersion: plus, re-implementing it yourself has security implications
13:02 Sumera[m]: danvet: yeah first patch doesn't make much sense rn... thanks for clearing it up tho :)
13:02 Vanfanel: emersion: you are right on that.
13:03 emersion: distributions will just package whatever you choose to depend on
13:03 Vanfanel: emersion: so... that libseat, does it depend on dbus, or logind or something like that?
13:03 Vanfanel: I don't want to depend on running services
13:04 danvet: if they're running it will use them, if not it'll do the arcane dance itself
13:04 Vanfanel: I use DRM-full SDL2 (if thats the name) without ANY services, not even systemd running
13:04 emersion: Vanfanel: it can be built with or without those, and it can run with or without those
13:07 Vanfanel: emersion: but the distro versions of libseat are built with those ON, so inslatting libseat will pull the systemd stuff, which I do not want on my minimal systems
13:08 emersion: depends what the distro is i guess. e.g. on alpine i'd expect seatd to not be built with elogind support
13:09 emersion: on systemd distributions yes it'll depend on libsystemd, but it's already there
13:09 emersion: example: alpine: https://pkgs.alpinelinux.org/package/edge/testing/aarch64/seatd
13:09 emersion: dependencies: just musl
13:09 Vanfanel: emersion: I want it to work without systemd or libsystemd or systemd services, on Debian and derivates
13:10 Vanfanel: so it will have to be arcane
13:10 emersion: i don't know about debian packaging policy
13:11 emersion: no, it doesn't have to
13:11 kennylevinsen: libseat for a systemd distro is built with systemd support, libseat for a non-systemd distro is built without. Regardless, it never requires systemd. libseat can use the embedded backend.
13:11 kennylevinsen: Vanfanel: If you wish to replicate all the arcane magic, you're of course welcome to do so. I would recommend reading seatd source, or maybe the wlroots direct backend (both freebsd and non-variants).
13:12 emersion: i'd really recommend against doing that.
13:13 Vanfanel: It's hard to ignore an advice like that... I thought it would come down to an ioctl() to block the keyboard on the tty. But it seems to be something far more complicated!
13:13 kennylevinsen: Indeed, I recommend against it too. You have to be prepared for a lot of platform details, vt modes, kernal console keyboard modes, async signal-based apis, drm/evdev ioctls, and countless corner-cases that are very hard to shake out and usually just leaves you with a broken VT you cannot leave after running for a while.
13:14 kennylevinsen: broken VT being that it's dead, not taking keyboard input and/or not letting you navigate away from it do to using the apis wrong
13:15 Vanfanel: it seems that libseat doesn't even exist as a debian package
13:15 kennylevinsen: it's very easy to get a simple initial thing to work, but even the small seatd project has been through many iterations of these details
13:17 kennylevinsen: getting things to work well, consistently, in more than a simple test is pretty hard - and in my case required reading linux and freebsd kernel VT code and again. :)
13:20 pq: Vanfanel, also if you want to handle program crashes so that the user is not locked out of his local console, that's very hard to make reliable without a helper process. Simply existing the program does not restore the local console.
13:20 pq: *exiting
13:21 pq: and restoring it takes a lot more than what you could do in e.g. SIGSEGV handler with good faith
13:23 kennylevinsen: at the bare minimum you need to set the keyboard mode (different modes depending on platform), set the kernel display and VT modes (slight platform differences in the fields), register VT process switching handlers and perform cooperative VT switching upon request (platform differences in ack requirements), which implies dropping/restoring drm master role and possibly revoking/reopening evdev devices, and of course ensure that
13:23 kennylevinsen: you manually undo all of this when the application goes away for any reason (including crash), as you otherwise have a system entirely unresponsive to physical input.
13:23 kennylevinsen: unless the game is to run as root, you will need a root helper process anyway to acquire/drop drm master.
13:25 pq: kennylevinsen, if you have a new enough kernel, drm stop/set master might not neet root per se.
13:25 pq: but I think that would be quite very new, IIRC
13:25 pq: *drop
13:26 pq: permissions for opening input devices is another matter
13:27 Vanfanel: pq: I will try to fix the key leakage (that only happens when the SDL2 apps are run thru ssh instead of on the local machine) and leave it there, so I may look at it again next year or someone else does.
13:27 Vanfanel: pq: This is where SDL2, when using the EVDEV interface, opens the keyboard: https://hg.libsdl.org/SDL/file/50326832c1f7/src/core/linux/SDL_evdev_kbd.c#l357
13:27 pq: Vanfanel, I'm pretty sure the key leakage happens regardless of ssh.
13:28 Vanfanel: pq: well, I have never seen it happen without SSH
13:28 pq: Vanfanel, it's just that the stdin is going to the SDL app instead of the shell, unless you starts the SDL app on the background.
13:28 pq: well, you can't "see" it, you see the SDL app :-)
13:28 Vanfanel: pq: ahh! I get you now...
13:28 Vanfanel: :)
13:29 Vanfanel: but it's happening anyway
13:29 Vanfanel: oh god... how can it be that no one has cared about this since 2014 when SDL2 was released?
13:29 pq: also, after starting graphics, you cannot expect printing to the VT works correctly
13:30 pq: so you can't trust that you would see the stuff you typed after you quit the SDL app
13:31 pq: however, if input is going to the VT, then I guess Ctrl+c should be able to send SIGINT to the foreground program...
13:35 Vanfanel: pq: hmm.. no, I can't quit SDL2 programs with CRTL+C
13:35 pq: Vanfanel, I see the "keyboard mute" code there. I suppose it's not working then?
13:37 Vanfanel: pq: do you mean the "ioctl(kbd->console_fd, KDSKBMODE, K_OFF);" line?
13:37 pq: yes
13:37 Vanfanel: pq: my theory is that it works.. except you run the app thru ssh.
13:37 Vanfanel: does that make that sense?
13:37 Vanfanel: *does that make sense?
13:37 pq: it's plausible
13:38 pq: this is the arcane magic
13:39 kennylevinsen: if console_fd isn't the tty for the VT, then yeah that won't work.
13:39 kennylevinsen: plus it won't work on freebsd, it doesn't have K_OFF.
13:41 Vanfanel: pq: then I will leave it like that. I don't mind that it fails on SSH.
13:42 Vanfanel: kennylevinsen: I don't think anybody is using SDL2 on KMSDRM on freebsd, but... what would be the way to do it there? is there an equivalent?
13:42 Vanfanel: Now that I think about it, there was a freebsd-related bugfix recently...
13:42 Vanfanel: so someone could be using that with SDL2 after all
13:45 kennylevinsen: on linux you generally toggle between K_UNICODE (or what it was before, in case it's K_XLATE) and K_OFF, while freebsd is K_XLATE and K_RAW, but then you also need to set the tty into RAW mode as keyboard input isn't *disabled*, just made more harmless.
13:47 kennylevinsen: and failing to restore this mode leaves you with a machine that does not accept phyiscal input. if SysRq is enabled on linux, you can escape with that. You can try to fix it over SSH, otherwise pull the plug.
13:51 pq: Vanfanel, did you notice the D-Bus code in SDL2? :-)
13:53 danvet: Sumera[m], can you pls review the fix from Colin for the vkms_config patch?
13:53 danvet: just showed up on the list
13:54 Sumera[m]: danvet: yep, taking a look
13:54 danvet: thx
13:54 Vanfanel: pq: nope. It's not affecting my usercase, anyway, so I don't have that code built :P
13:57 Vanfanel: kennylevinsen: so in freebsd I have to set the keyboard to K_RAW, and then back to K_XLATE, and the TTY into K_RAW too?
13:57 Vanfanel: I don't even have a freebds machine to test, honestly
13:58 Sumera[m]: danvet: lgtm. what exactly does 'reviewing' mean? Apart from testing it which I'll do now.
13:59 danvet: https://dri.freedesktop.org/docs/drm/process/submitting-patches.html?highlight=reviewer%20statement%20oversight#reviewer-s-statement-of-oversight
14:00 danvet: i.e. if you're happy with a patch, you reply with a Reviewed-by: with your name+mail address on it
14:00 danvet: and melissawen can then merge it or me
14:05 kennylevinsen: Vanfanel: this will need a fair amount of testing, which is also why it isn't fun to reinvent as opposed to sharing...
14:10 Vanfanel: kennylevinsen: I see
14:13 emersion: you could just vendor libseat and statically link to it if it must come to that
14:15 Vanfanel: emersion: vendor? There's no business around all this, I do this for fun (more or less). Do you mean that I should link statically against a libseat version I build at home? I don't think the SDL2 people would approve that requeriment
14:15 emersion: vendoring means copy-pasting source code in your tree
14:16 Sumera[m]: danvet: done
14:16 emersion: i don't like it, but some projects like it
14:16 Vanfanel: emersion: oh, I get it. Like those projects that include 3rd party lib sources on they sourcetree, right?
14:17 emersion: yea
14:17 Vanfanel: *their
14:21 melissawen: Sumera[m], danvet, about the mentioned virtual_hw patch, I think it does not totally work. It does not care about CRC/set_composer behavior, that is currently tied to vblank op
14:21 Vanfanel: emersion: just as a curiosity, I thought you meant "seller", because in spanish "vendor" is similar to "vendedor", which is the word for "seller" :P
14:22 emersion: eh
14:54 mareko: Kayden: you shouldn't have a problem with draw merging in tc because all drivers support multi draws now
14:58 daniels: Vanfanel: same etymology in English
15:13 siqueira: Hi danvet melissawen
15:13 siqueira: In the amdgpu driver, there is a file named dce_virtual.c, which is a pure software modesetting implementation (not atomic). We use it for virtualization, for hw without display blocks, emulations when display hw is not available, and others. In this sense, agd5f_ and I discussed if it would make sense if we can hook into vkms instead of rework
15:13 siqueira: dce_virtual. Imho, it looks like an interesting use case for vkms. Do you have any thoughts about it?
15:15 danvet: siqueira, you mean like vkms as a helper library to instantiate some fake display?
15:16 danvet: but not as a separate drm device instance, but on your own?
15:17 danvet: siqueira, also why do you set this up for hw without display blocks?
15:17 danvet: I mean outside of pre-silicon/testing stuff
15:18 danvet: userspace shouldn't die just because there's no crtcs ...
15:24 siqueira: I considered using it as a separate drm driver where other gpus could just use the vkms for fake displays (maybe we could use configfs to setup these things). With that, I expected to reduce code maintainability (e.g., we could eliminate dc_virtual and rely only on vkms). I did not think about it as a helper, but it might work as well.
15:25 danvet: oh if it works for you just loading it, that should be all ok
15:26 danvet: I think prime and everything should be all wired up to make this Just Work
15:27 danvet: siqueira, I asked since I was kinda assuming you're tooling expects something that looks like a real amdgpu
15:27 danvet: i.e. with planes on it
15:27 danvet: but if you just need a display, and it's ok to be a separate drm_device instance
15:27 danvet: it should all work already
15:28 danvet: including crcs even :-)
15:28 danvet: siqueira, the helper library approach would be a bit icky, since the global callbacks are shared
15:28 danvet: like atomic_commit_tail
15:29 danvet: also would need to make sure nothing goes through the drm_device
15:29 danvet: hm ...
15:29 danvet: siqueira, helper library sounds like quite some work and maybe a bit fragile
15:36 siqueira: Yes, I would prefer to avoid the helper library for this case. Another question, I was thinking about the framebuffer handling between real GPU and VKMS; prime is the component that could help me here? Maybe something else? Or I'm misunderstanding some concept here?
15:47 danvet: siqueira, should work like any other multi-gpu system, with prime
15:47 danvet: vkms should even follow implicit fencing
15:47 danvet: so aside from you having 2 drm_device instances, it should be all the same
15:47 danvet: siqueira, we could even add support for amdgpu modifiers (and other pixel formats) if you need those
15:48 danvet: might get a bit tricky wrt crcs, since we'd need to decode the tiling layout
15:48 danvet: so also probably no compression
15:52 vivijim: airlied: please consider pulling both drm-intel-next and drm-intel-gt-next so we can do the proper backmerges to get them back to sync
15:53 siqueira: Cool! Thanks danvet for the detailed explanation; I'm going to take a close look at that; now I think it is really doable to use VKMS for this context. agd5f_ do you have any other concerns about that?
15:55 ajax: /win goto #freedesktop
15:55 ajax: ngh
16:17 agd5f_: using it like prime complicated things a lot. I'd prefer to just have a helper like interface where we expose the KMS API and sw objects, but the driver provides real framebuffers
16:19 MrBIOS: hi folks, I was wondering if Mesa is planning on dropping DRI support in the near future? I've only heard unconfirmed rumors.
16:20 imirkin: what would be the alternative?
16:20 jenatali: Exactly what I was wondering
16:22 hch12907: probably meant to say classic DRI drivers?
16:22 imirkin: MrBIOS: ah, classic vs gallium?
16:22 MrBIOS: yes
16:23 imirkin: it's a thought that has occurred on a few occasions, but hasn't really gone beyond the thought phase afaik
16:23 imirkin: first off, intel pre-broadwell support is classic-only right now
16:24 MrBIOS: right, I'd imagine it's still a few years off still.
16:25 hch12907: the pre-8.0 DRI1 drivers are dropped iirc
16:25 imirkin: yes, they were dropped in 8.0 ;)
16:27 hch12907: ugh... got them confused. Support for loading DRI1 drivers was dropped a month ago.
16:27 imirkin: yes.
16:28 imirkin: some amount of compatibility was kept in the loader, which i guess has gone away
16:28 imirkin: with libglvnd, that's no longer really necessary
17:28 zmike: mareko: is it documented anywhere the general flow of gallium updates? i.e., do shaders always get bound before descriptors or vice versa? or is that not reliably ordered
17:39 anholt: zmike: not documented, not validated, also unlikely to match up with ordering of state updates in things like u_blitter
17:39 zmike: ok, just checking 👍
17:40 zmike: kind of a shame though, could do some neat optimizing if e.g., shaders were guaranteed to be bound before descriptors
17:42 imirkin: zmike: "descriptors"?
17:42 imirkin: these things can change in any sequence
17:42 zmike: yes, but gallium is able to batch and reorder things, so that doesn't have to be the case
17:43 jenatali: Does moving the reordering from the driver into gallium really solve that much though?
17:43 imirkin: why does a driver care? doesn't that just add overhead?
17:43 imirkin: i realize when your target "hw" is vulkan this matters, but for regular hw drivers ... who cares
17:43 zmike: shrug
17:43 zmike: just a question
17:44 imirkin: to answer your question, the ordering is well-defined: any order is legal.
17:44 imirkin: including doing clears without any e.g. blend state bound.
20:04 anholt: ajax: at a total loss as to how that mr could break z24s8
20:18 airlied: vivijim: pretty sire I pulled both yesterady into drm-next
21:28 imirkin: hmmmm
21:29 imirkin: if you do a glFramebufferTexture2D on the currently-bound framebuffer, followed by a glClear, it doesn't appear that we ever validate it, so it's marked as incomplete
21:30 imirkin: i guess something's missing a _NEW_BUFFERS setting
21:31 jadahl: is the gbm EGL platform supposed to be work when opening a render node device and not a card device? I keep getting the llvm renderer unless I create a surfaceless egl display where I get a proper intel renderer
21:34 imirkin: hm, no, that's not it
21:34 imirkin: we do a FLUSH_VERTICES(ctx, _NEW_BUFFERS); at the top of mesa_framebuffer_texture
21:38 mareko: zmike: drivers shouldn't expect a predetermined order, but st/mesa does them for regular draw calls in the order specified by st_atom_list.h
21:42 zmike: mareko: 👍 thx for confirming
21:50 imirkin: yeah, nevermind about my question. mesa core is fine. i misread the nouveau format table.
21:56 vivijim: airlied: ops, sorry... I got confused here with my tig... thanks for pulling them
22:09 emersion: jadahl: yes it's supposed to work
22:09 emersion: we use it in wlroots
22:09 airlied: vivijim: no worries, it wouldn't have surprised me in the least if I'd done it locally and forgotten to push it out
22:10 emersion: 00:00:00.011 [wlr] [backend/wayland/backend.c:411] Opening DRM render node /dev/dri/renderD128
22:10 emersion: 00:00:00.062 [wlr] [render/gles2/renderer.c:893] GL renderer: AMD Radeon(TM) Vega 8 Graphics (RAVEN, DRM 3.40.0, 5.10.6-arch1-1, LLVM 11.0.0)
22:10 emersion: definitely working for me
22:15 jadahl: emersion: maybe my mesa is borked
22:21 jadahl: or no, unlikely, but opening /dev/dri/renderD128, turning it into a gbm device and creating an egl display here leaves me with an llvm renderer.. :|
22:22 emersion: out of curiosity, why are you trying to do this?
22:23 jadahl: getting an egl display/context/.. without being drm master
22:23 jadahl: i can get surfaceless to work just fine, but not the gbm platform
22:24 emersion: yeah but, why use the GBM platform?
22:24 jadahl: to select the right device manually
22:24 emersion: ah. you could also use EGLDevice, but that's more typing i guess
22:25 emersion: maybe the various EGL/Mesa debugging env vars can tell more
22:25 jadahl: i was hoping to be able to have drm nodes open, one renderer, and one card0 that comes and goes, where I would be able to allocate and render things on the renderer, turn things into dma bufs, and hand over to the other
22:26 emersion: if not, then i'd just switch to a locally-compiled mesa and start debugging it
22:26 jadahl: i debugged it into some iris bo mmap thing failing deep down the tree
22:26 emersion: does it work if you force i965?
22:26 jadahl: no
22:27 jadahl: but for some other reason iirc
22:27 emersion: fwiw, this idea of having one renderer that hands stuff to display via dmabufs is exactly what wlroots is doing
22:29 jadahl: are the renderer operating on /dev/dri/render* and the handing over things to another fd opened from /dev/dri/card*?
22:30 emersion: depends. right now, on DRM everybody uses card*, and on headless/wayland/x11 everybody uses render*
22:30 emersion: but i don't see why it wouldn't work
22:30 jadahl: and all gbm platform and no surfaceless?
22:30 emersion: GBM is used unconditionally yes
22:31 emersion: although we'll switch to EGLDevice at some point
22:31 jadahl: yea i don't see why it doesn't. also passed by a couple of "if (renderer_node) do_this(); else do_that()" which made be believe it should work, but then some memory map thing failed or something
22:31 emersion: i can try on my intel test machine tomorrow
22:33 emersion: just fyi, i've been hitting some small issues with this approach -- e.g. vaapi being broken (patch sent and merged), nouveau issues (still investigating)
22:33 emersion: but in general it's working fine
22:33 jadahl: due to the renderer / card split?
22:34 emersion: vaapi was because of using a render node for the GBM platform
22:34 emersion: it didn't realize that it doesn't need to authenticate when it has a render node, and it just failed
22:34 emersion: nouveau, not sure yet, there are multiple issues
22:36 jadahl: thats good to know, thanks for the heads up
22:49 imirkin: a question came up about whether GL_RGB16 texture attachments should be required in GL impls -- in case someone who has a good understanding of these requirements feels like commenting: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4101
23:07 jadahl: emersion: manage get the error code from the failed mmap.. EPERM *facepalm* I had written RDONLY instead of RDWR by accident in one place
23:19 emersion: ahah
23:22 jadahl: emersion: I even gdb-stepped passed by a few places in mesa that open()s the file itself with RDRW and I told myself "I did that too" :P
23:37 dcbaker: fg
23:37 dcbaker: oops
23:38 anholt: dcbaker: any clue about https://gitlab.freedesktop.org/mesa/piglit/-/issues/47 ?
23:39 anholt: (specifically our test list changing, not just the extensions list ordering that my command catches)
23:39 dcbaker: anholt: Ohhhh. I know what that is
23:39 dcbaker: let me see if I can remember
23:40 anholt: I looked and python random is stable with the seeding we've got going on
23:40 dcbaker: I know what the problem is (or did) but I seem to remember it's really awful to fix
23:41 dcbaker: annd: https://gitlab.freedesktop.org/mesa/piglit/-/issues/10
23:41 dcbaker: I just need to finish writing that C program
23:41 dcbaker: or someone does
23:45 dcbaker: I'm tired of trying to fix meson bugs that I can't reproduce on my local system, so maybe it's time for writing some piglit code
23:48 anholt: dcbaker: I don't see any explanation in that issue for where the variation comes from
23:52 anholt: maybe it's that FilterVsIn is taking in a shuffled sequence of tests and so picking a random subset?
23:53 anholt: if it's just vs_in, that set is disabled in mesa ci because of its instability (.gitlab-ci/piglit/disable-vs_in.diff)
23:53 dcbaker: I'm pretty sure it is just the vs_in tests
23:54 anholt: hmm. well, we're seeing build-dependent test behavior in mesa ci even with those disabled
23:55 dcbaker: dang, I was hoping that would be it
23:58 dcbaker: is the `shader.xml.gz` the same on both runs?
23:58 anholt: let's see if I can find two corresponding runs from mesa ci