06:12agrisis: any idea why I might not be able to switch ttys with chvt(1) when I have a drm app running?
06:13agrisis: it seems to work under systemd but not a non-systemd OS
06:13agrisis: if I stop the drm app then I can see tty switching works
08:00emersion: the drm app needs to properly support tty switching
14:11DPA: agrisis: Do you have elogind installed?
14:27Lightkey: ajax: features.txt still lists softpipe for GL_ARB_framebuffer_no_attachments even though it's all DONE for GLES 3.1.
14:41agrisis: DPA: no I don't have elogind enabled, I can give that a try
14:57agrisis: DPA: didn't seem to work
15:02agrisis: I also tried ngetty instead of agetty but that doesn't seem to help
15:03agrisis: for some reason if a drm app is running on tty1 I can't chvt 2, although if I do that and stop my drm app then I see tty2 is there
15:09agrisis: hmm using kmscon I get [0000.163910] ERROR: drm_shared: cannot set DRM-master
15:12xexaxo1: agrisis: depending on how buggy the application is (among others), https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.10-rc1&id=45bc3d26c95a8fc63a7d8668ca9e57ef0883351c may help
15:14xexaxo1: agrisis: as a quick check - run the app as root. if that works the kernel patch will help
15:14agrisis: xexaxo1: I'm on kernel 4.4.189 and this exact software and setup worked on Archlinux systemd
15:14xexaxo1: agrisis: look at the commit mentioned - it explains why/how things work for systemd, and why they don't otherwise
15:15agrisis: xexaxo1: ah
15:15xexaxo1:grabs some food
15:15agrisis: thank you
15:25DPA: elogind is technically a fork of systemd, which should do exactly what logind usually does in these situations.
15:25DPA: Maybe elogind isn't being used? maybe try to LD_PRELOAD it?
15:26karolherbst: DPA: software also needs to be compiled in order to be able to make use of it
15:26karolherbst: maybe that's the problem
15:26pcercuei: Re: using video= parameter to force the framebuffer console's resolution
15:26karolherbst: thinking about gentoo with -systemd -elogind
15:26pcercuei: It only works if the requested resolution is natively supported by the connector
15:27LiquidAcid: karolherbst, is that even possible nowadays?
15:27karolherbst: of course
15:27LiquidAcid: karolherbst, i used these flags when consolekit was still alive
15:27karolherbst: but yeah...
15:27pcercuei: So I cannot use my plane to scale the emulated framebuffer to the connector's resolution...
15:27karolherbst: no idea, some people still seem to care about not having systemd installed
15:27karolherbst: I guess they will put their efforts into making it work
15:27LiquidAcid: but's gone since some months from the portage tree, and i don't know what else manages logins then (if not elogind)
15:28karolherbst: didn't know it got removed finally
15:28DPA: karolherbst: libelogind It's pretty much a drop-in replacement for libsystemd, they usually have a compatible ABI. If the application was compiled to work with the latter,
15:28DPA: preloading elogind or replacing libsystemd should make it use elogind.
15:28karolherbst: but what if you didn't use elogind/systemd before
15:29karolherbst: but it could also be devuan and theyr userspace from the 90s :p
15:29DPA: karolherbst: I'm using devuan, it's mostly identical to debian, and it works really well.
15:30karolherbst: not saying it doesn't work
15:32karolherbst: I just can't take an OS serious which still uses sysvinit
15:33DPA: karolherbst: It also other init systems, such as openrc. openrc may even become the default at some point.
15:33DPA: *also supports
15:34karolherbst: that doesn't make it better.
15:34karolherbst: just use openrc, which is in all areas better as sysvinit at least
15:34LiquidAcid: i use openrc on most system, but not exclusively
15:34LiquidAcid: systemd also has its merits
15:34karolherbst: it does
15:34karolherbst: and hence I didn't compre openrc to systemd
15:35EdB: I'm the only one to have problem connecting to mesa git using ssh ?
15:35karolherbst: but sysvinit... seriously
15:35LiquidAcid: karolherbst, i didn't say you did
15:35EdB: *Am I
15:35agrisis: DPA: yes I was hoping elogind would work for me
15:35agrisis: kmscon also doesn't provide a tty either
15:36agrisis: this is Void Linxu and using runit but I doubt that should matter
15:36agrisis: not sure what else I can try
15:36karolherbst: agrisis: did you enable elogind/
15:36agrisis: karolherbst: I did
15:36agrisis: should I also disable agetty?
15:36karolherbst: seems like you also need dbus and polkitd
15:37agrisis: I have dbus but not polkitd
15:37karolherbst: agrisis: got it from here: https://wiki.voidlinux.org/Post_Installation#Seat_management
15:38karolherbst: but mhh
15:38karolherbst: the new handbook doesn't mention it
15:38karolherbst: oh well...
15:39karolherbst: you'll figure it out
15:39agrisis: enabled polkitd, dbus, elogind still to no avail
15:40karolherbst: ohh wait
15:40karolherbst: you just run an drm app directly on the tty, right?
15:40karolherbst: nothing in between, correct?
15:40karolherbst: ahh yeah
15:40karolherbst: the application has to implement tty switching then
15:40agrisis: this is retroarch and afaik, this workflow worked on Archlinux w/ systemd
15:41DPA: Isn't that why libpam-logind exists though?
15:42karolherbst: might be
15:42karolherbst: but then one needs to essentially reboot the machine anyway
15:42karolherbst: so that the login thing picks it upt
15:44agrisis: when I do `sudo chvt 2` with retroarch running on tty1, if I quit retroarch I see that indeed it's in tty2
15:44agrisis: it's just that I can't see the tty2 login when switching either with chvt or with ALT+F2
15:45agrisis: on archlinux in my retroarch service, I had to do: StandardInput=tty-force, StandardOutput=tty, TTYVHangup=yes, TTYPath=/dev/tty1, TTYReset=yes
15:45agrisis: I think those were needed for it to work
15:46agrisis: god knows what those settings are doing but it could be the ticket
15:47DPA: agrisis: could you check with ldd if the application links against libsystemd or libelogind, and if the former, if libsystemd is provided by elogind or something else?
15:47agrisis: DPA: it's defintely not because I compiled it in a chroot and didn't have libsystemd or libelogind there
15:48agrisis: DPA: do you think if I recompile it with elogind added it might help?
15:48DPA: agrisis: Maybe. I think it's worth a try.
15:48karolherbst: anholt: do you know if the configure step checks for those libs?
15:49karolherbst: I meant agrisis
15:49agrisis: I doubt it, but I can check
15:50agrisis: karolherbst: it doesn't pick up libelogind
15:52karolherbst: mhh it does check for systemd though
15:52agrisis: but other drm apps like supertux would also be expected to do the same in userspace?
15:56DPA: karolherbst: This kind of lock-in is exactly why I can't take any OS running systemd seriously.
15:57karolherbst: what lock-in? it provides features and if you want it, you use it
15:57karolherbst: or you implement it all yourself
15:57karolherbst: your choice
15:57emersion: you might be interested in https://git.sr.ht/~kennylevinsen/seatd/
15:57emersion: as an alternative to logind
15:57emersion: also provides a lib that does everything for you
15:58agrisis: kmscon --vt 2 --no-drm flashes the screen but I don't get a login prompt
16:00DPA: karolherbst: As you can see here, the structure of systemd leads to that being very difficult, and it leads to systemd being installed.
16:00DPA: As long as people end up having to install systemd, it's lock-in. The theoretical possibilities are irrelevant at that point.
16:00karolherbst: so what? people have to use the linux kernel for a lot of stuff to, that's really a nonesense argument (or Xorg)
16:00agrisis: this is an embedded platform, I found void linux package management to be very amenable to cross compiling in a sane way which is why I chose it
16:00karolherbst: those things exists
16:01karolherbst: and you are free to either provide your own implementation
16:01agrisis: archlinux ran fine but runit is much less overhead and faster than systemd
16:01karolherbst: or create another API others are willing to use and support
16:01karolherbst: systemd does solve a lot of issues
16:01agrisis: I will keep trying to make this work as it's the only regression since switching
16:01karolherbst: and I am tired of those types of people having no clue and that's why the linux desktop is for most parts still in the year 2000
16:02karolherbst: if you want to have a great replacment for systemd, go ahead and write it
16:02karolherbst: nobody prevents you from doing it
16:02karolherbst: and if it's really well made and actually useful, others might see it and start supporting it
16:03karolherbst: but the reality is, everything else sucks more than systemd
16:04agrisis: also confirmed I can't switch ttys with mpv playing either
16:04karolherbst: alone the dhcp client situations is a mess
16:04agrisis: agreed re: dhcp
16:04karolherbst: we have like what, 5 clients all with different APIs and everybody has to support all of them?
16:04karolherbst: or just use the new systemd thing...
16:05agrisis: not to mention how many network management systems are out there
16:05karolherbst: the situations was terrible pre systemd
16:05karolherbst: and now systemd at least tries to be _one_ provider of system level core services
16:05agrisis: it's impossible for an app to provide a single way of "connecting to a wifi" as there is wpa_supplicant, networkmanager, netctl, etc..
16:05karolherbst: so everybody can just use this one instead of having to support 5 of each service
16:06karolherbst: that's why people use systemd
16:06karolherbst: because it reduces sotware maintanence costs
16:06DPA: karolherbst: I don't want to replicate systemds misdesign. Making it so that systemd is needed if any unrelated features are needed, is the problem.
16:06DPA: Making unrelated things depend on each other, that's the problem. Solving this issue would require making the unrelated parts into unrelated, independantly
16:06DPA: functioning APIs. It would require changing systemd, and thats not gonna happen in that way.
16:06LiquidAcid: to be fair, systemd still needs wpa_supplicant
16:06karolherbst: DPA: systemd doesn't do it
16:07karolherbst: that's just repeating the same missinformation everybody repeats with systemd
16:07karolherbst: it's a big project sure, it does have a lot of things, but it's not one binary
16:07agrisis: so I have another question for you all, this embedded system requires rotation as the lcd doesn't provide it, what we're doing is each app has to be patched to call into librga and do rotation and hw scaling there
16:07karolherbst: LiquidAcid: because networkmanager uses it
16:07DPA: karolherbst: It does! Just look into how many APIs are merged into the same libsystemd library, for example.
16:08agrisis: https://github.com/hizukiayaka/librga that's the library we use
16:08karolherbst: DPA: did you even udnerstood what I said?
16:08karolherbst: people don't want to have to target 5 different aPIs
16:08agrisis: I was wondering if I could maybe do this rotation in the kernel?
16:08karolherbst: at the same time
16:08agrisis: I'm using rockchip drm
16:08LiquidAcid: karolherbst, no, i use networkd on one system and you need wpa_supplicant if you wanna do anything related to wifi
16:08karolherbst: and that's the strongets argument for systemd
16:08agrisis: because in userspace, we need to blit the buffer and call ioctls then call into drm
16:08karolherbst: and everything else just doens't matter if a replacement can't do at least this
16:09karolherbst: LiquidAcid: ahh
16:09karolherbst: but yeah
16:09karolherbst: the wifi daemon is still a WIP thing afaik
16:09karolherbst: intel works on a replacement afaik
16:09agrisis: for example, mpv playing is not rotated, I need to patch it with a lot of crappy code to this in userspace
16:09agrisis: I suppose I could patch libdrm itself to automatically do this rotation?
16:10agrisis: the screen is 320x480 but layed out horizontally, so I would probably need to also change the resolution that is returned
16:10agrisis: and I don't think libdrm does that, but it's done from the kernel itself
16:10DPA: karolherbst: And its the very argument against it. Forcing an API on people, regardless of how, intended or not, is lock-in.
16:10DPA: And lock-in is the one thing I try to avoid by using linux in the first palce.
16:10karolherbst: DPA: ... nobody is forced to use it
16:11karolherbst: but it's used as it solves problems
16:11LiquidAcid: agrisis, why not just use mpv's --video-rotate?
16:11karolherbst: what you do is to just go again and again on "how all of that is lock-ing"
16:11agrisis: LiquidAcid: I was hoping to fix this upstream in my system rather than provide these workarounds for each individual app
16:11agrisis: LiquidAcid: we've also patched SDL2 to do this rotation automatically
16:11karolherbst: it's not, it's just there is nothing which even comes close
16:11agrisis: LiquidAcid: and the librga chip is hw rotation and scaling which is faster than doing it in software
16:12DPA: karolherbst: If nobody's forced to use it, I'm glad to see how nobody is having exactly that problem right now.
16:12agrisis: I guess I could install gentoo on this embedded device and see if it is able to switch ttys
16:12agrisis: maybe they managed to solve something
16:13karolherbst: DPA: besides the point. The thing is, nobody is willing anymore to support anything else
16:13LiquidAcid: agrisis, you mean it's something like the exynos rotator?
16:13karolherbst: if users want to do otherwise, they are on their own
16:13karolherbst: and the distributions are so as well
16:13agrisis: LiquidAcid: I'm not familiar with that, but perhaps
16:13karolherbst: and if you go for a less optimal solution, tough
16:13karolherbst: but you brought it on your own
16:14karolherbst: I think you just have the wrong definition of a lock-in
16:14LiquidAcid: agrisis, it's basically a simplified bitblt engine that does rotation (in 90 degree steps), reflection, etc.
16:14karolherbst: lock-in doesn't mean that alternatives should be bugfree
16:14agrisis: LiquidAcid: yeah precisely
16:14agrisis: LiquidAcid: let me give you an example of what it looks like
16:15karolherbst: and again, if you want to make a systemd replacement with a good API, just do it
16:15LiquidAcid: agrisis, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/exynos/exynos_drm_rotator.c
16:15agrisis: LiquidAcid: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/oga_gfx.c#L606
16:15karolherbst: but as it seems, nobody is willing to spend the time on it
16:15karolherbst: making the entire discussion just utterly pointless
16:15LiquidAcid: agrisis, it's exposed via the IPP API (so exynos specific)
16:16LiquidAcid: probably not what you're looking for
16:16agrisis: LiquidAcid: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/oga_gfx.c#L633 that's the drmMode ioctl and above it you can see that it rotates 270
16:17DPA: karolherbst: I don't think this is a bug in the alternative. Having libelogind not being named libsystemd, is a compromise to not clash with other things.
16:17agrisis: so in userspace, the screen is 320x480 but we work with 480x320 framebuffers and then before the drm commit, we rotate the screen from 480x320 to 320x480 then call drm
16:18agrisis: would be great if this could be done in libdrm or the kernel itself, and when we query the screen res it returns 480x320 and just does all that internally
16:18karolherbst: DPA: ehh.. it's a dbus API
16:18agrisis: plus I imagine it would save some context switches
16:19DPA: karolherbst: That doesn't help with the configure scripts which don't detect it.
16:19agrisis: or going further, I'd like to expose a scaling option in /sys so if the user is rendering to 256x224 and you set /sys/.../scaling -> 1, it would automatically call into the rga chip to scale 256x224 to 480x320, etc..
16:19karolherbst: DPA: because they don't have to as there is no need to link
16:20LiquidAcid: agrisis, i doubt you get something like that upstream
16:20karolherbst: but sure, the configure scripts could try to detect what is used and so
16:20karolherbst: but it's really not required
16:20agrisis: LiquidAcid: https://github.com/hardkernel/linux/tree/odroidgoA-4.4.y/drivers/video/rockchip/rga2
16:20karolherbst: you can just check at runtime if it's there or not, or you check for the dbus interface file to be there
16:20LiquidAcid: agrisis, i remember the discussion when the ippv2 api was upstreamed, was supposed to be a generic api at first
16:20agrisis: LiquidAcid: that's the RGA2 kernel driver I'd like to use
16:20karolherbst: checking for libsystemd is really the wrong choice here
16:21LiquidAcid: agrisis, yeah, well, that's a proprietary hardkernel tree, and we all know how good hardkernel is a upstreaming
16:21karolherbst: also, why would you want to force build servers to install systemd if there is really no need?
16:21agrisis: LiquidAcid: oh I didn't know they had a history!
16:22agrisis: I thought rockchip was the problem?
16:22LiquidAcid: agrisis, you mean a history of not doing anything? :D
16:23agrisis: well I think this kernel branch at least is based from rockchip and they just do a bit of tweaking to make it work for their devices
16:23DPA: karolherbst: I need systemd features, let's just add a dependency. It's the convinience and simplicity of using it for which it get's used in the first place.
16:24karolherbst: we are just coming back to my original point that peopel are not willing to deal with 5 APIs doing the same thing
16:24karolherbst: it could be so easy
16:24karolherbst: just use systemd and everything just works
16:24karolherbst: but no
16:25karolherbst: people doesn't like it and uphold the "falacy of choice"
16:25agrisis: karolherbst: do you suppose my issue of not being able to switch ttys existed pre-systemd and systemd solved this?
16:25karolherbst: you just make it more painful for developers
16:25karolherbst: and making it more painful for developers is really something we don't need with our system being from 2000
16:26karolherbst: agrisis: let's say that seat management is a difficult problem and we had other solutions for it, but it all sucked quite a lot
16:26karolherbst: logind really helps here
16:26agrisis: maybe elogind doesn't fully implement it on my system then
16:27karolherbst: might be
16:27karolherbst: or the build system needs to be adjusted
16:27karolherbst: who knows
16:28DPA: I'm sure the whole systemd situation will resolve itself one way or another someday. Hopefully in a positive way.
16:29karolherbst: well, it's already on the right path
16:30karolherbst: systemd brought the desktop into the year 2000 :p
16:30DPA: I'm worried as to where this path will lead. I think it's the wrong one.
16:31karolherbst: and maybe in the near futures we will have wayland compositors being able to recreate GL/Vk contexts on the fly, doing per GPU compositing and we will arive in 2010
16:31karolherbst: DPA: macos is good because it doesn't have to deal with this bs of choice :p
16:31karolherbst: and even windows overtook the linux desktop
16:31karolherbst: macos is just 20 years ahead
16:31karolherbst: but sure
16:31FLHerne: DPA: It's already resolved itself except a relatively tiny number of holdouts :p
16:31karolherbst: we can still continue clinging to the past and waste our time on maintaining 5 alternatives for everything
16:32karolherbst: nobody wants that anymore
16:32karolherbst: so we have systemd
16:32karolherbst: just suck it up
16:32ccr: future is gnome 3!
16:32FLHerne: Every major distro is using systemd, all the major DEs have various features that integrate with it
16:32karolherbst: ccr: not wanting to coment on the design of gnome, but mutter _is_ one of the best/stable wayland compositors
16:32DPA: Choice is good, it's the only way to prevent getting abused by bad software.
16:32karolherbst: it's still has a lot of things to change/fix though
16:33karolherbst: DPA: sure, but you can always reimplement an API
16:33karolherbst: or make slight adjustments
16:33karolherbst: and convince others to use it
16:33karolherbst: you make it sound like that people were forced to support systemd
16:33karolherbst: but guess why so many are actually only supporting this by now
16:33karolherbst: as there is _no_ alternative
16:33karolherbst: nothing even comes close
16:34karolherbst: from a "I design my OS/distribution" perspective
16:34karolherbst: and all people arguing against systemd never see this
16:34karolherbst: and they don't want to
16:34kisak: dumb question: why is this topic from years ago getting rehashed here? all of this has been discussed to death elsewhere.
16:34karolherbst: you just go back to this "they decided differently, clearly systemd is not about choice"
16:34karolherbst: and think you know better
16:34karolherbst: and everybody else knows worse
16:34karolherbst: but guess what
16:35karolherbst: kisak: yeah.. sorry
16:36karolherbst: talk about this agian once you maintain your entire distribution which is actually used by a lot of users, not one of those less than 1k users thingies.
16:37DPA: It's on my todo list, but I fear it'll take longer than a lifetime...
18:28imirkin: can someone remind me where i start to do an xorg driver release? it's stuff in xorg-modular and i just look at the readme? (i do it so rarely, that i forget in between releases)
18:29imirkin: ah hm. definitely not the readme...
18:31imirkin: ah, i just run release.sh i guess?
18:33dcbaker[m]: That is the upload the tarballs and create the announce email script
18:33imirkin: is there more to it?
18:33dcbaker[m]: I'm not sure what you need to do before that for xorg
18:34imirkin: iirc you give the script a tag and it adds the tag as well?
18:34dcbaker[m]: Mesa had some other scripts for creating release documentation that goes on the website
18:34imirkin: i do this approximately every 2 years, so ... i forget some of the details
18:34imirkin: and it usually doesn't work for one reason or another :)
18:35imirkin: but i think it eventually succeeded last time. but there was a gitlab migration since then, so ... we'll see.
18:35dcbaker[m]: The script derives the tag from the commit
18:35dcbaker[m]: The top commit
18:35imirkin: aha ok
18:36imirkin: iirc it also does some weird thing where it checks out a fresh repo, although that's probably for the clean tgz aspect
18:36dcbaker[m]: When I forget I just check git log for what the last person did, lol
18:37imirkin: need to get my gpg key in order too. thankfully that hasn't expired yet.
19:13alanc: imirkin: https://www.x.org/wiki/Development/Documentation/ReleaseHOWTO/ should cover it
19:18imirkin: alanc: awesome, thanks!
19:50agrisis: LiquidAcid: https://github.com/libretro/RetroArch/issues/7797 looks like someone else had the issue
19:50gitbot: libretro issue 7797 in RetroArch "KMS: Implement VT switching" [Bug: Kms, Feature Request, Known Limitations, Platform: Linux, Open]
19:50agrisis: and it's probably some magic that elogind or systemd is doing
20:44DPA: After a quick grep for systemd, logind and org.freedesktop.login1 in the retroarch repo, and looking at gfx_ctx_drm_init,
20:44DPA: it doesn't look like it uses any of those for anything related to this after all.
20:45DPA: Since it presumably worked somewhere at some point, I wonder if it may have used a different backend than the drm/kms one in that case?
20:58DPA: agrisis: It seams to have a wayland and an X backends, maybe you could start it on top of one of those?
21:11igorkovalenko: hi, I cannot start firefox Nightly with mesa change 57effa342b75a2ae681f2a7665925022dd6e4aa9
21:11igorkovalenko: firefox: ../src/mesa/state_tracker/st_nir_builtins.c:97: st_nir_finish_builtin_shader: Assertion `!"unsupported shader stage"' failed.
21:11igorkovalenko: is this a known issue?
21:13igorkovalenko: it works with llvmpipe but not with r600 here
21:16agrisis: DPA: nope, I manage a void linux and archlinux image for this embedded device and it definitely works on ubuntu, archlinux debian, same kernel, same retroarch build
21:16agrisis: DPA: it's gotta be some systemd/logind magic that is going on in those distros
21:16agrisis: DPA: also I don't have wayland/xorg on this device
21:17agrisis: well here's some interesting news... kmscon alone on tty1 and I'm able to chvt switch!
21:18agrisis: so I guess without whatever help systemd provides, kmscon is doing something right
21:19agrisis: but at the same time that kind of sucks because I don't wanna have to patch every single userland app to make kms tty switching work
21:20DPA: agrisis: RetroArch also seams to have an fbdev and an SDL backend. Maybe it just fails to use kms and falls back to one of those?
21:20DPA: Maybe check in "ls -l /proc/[pid]/fd/" if a /dev/dri/* device, or if a /dev/fb* device is used?
21:21DPA: Where pid is the one from retroarch.
21:21agrisis: https://pastebin.com/hBwDQMxG that is the output when I switch ttys from kmscon
21:21agrisis: DPA: no it's definitely using kms/drm, I wrote the graphics driver in retroarch
21:22agrisis: well I guess the good news here is we know systemd did at least one thing right
21:22agrisis: I bet systemd manages those seats (logind) and does all this hoopla transparently for you
21:22agrisis: now the question is why doesn't elogind do the same
22:06igorkovalenko: added comment regarding my firefox with r600 to MR !6477, llvmpipe still works
23:04rcdrone: is the mesa gitlab down?
23:05karolherbst: looks like it
23:06rcdrone: looks like it's back
23:11karolherbst: ehh.. seems like it's a bit messy atm
23:12dcbaker[m]: They're doing some maintenance I think
23:12dcbaker[m]: I saw something on #freedesktop about it
23:15daniels: yep, had to take a few minutes of downtime to fix an issue, all back and healthy
23:33karolherbst: cool, thanks!