ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<karolherbst>
yeah.. huh.. I'm not sure if the dword lowering mareko came up in 19399 is actually correct with random alignments... like it turns vec16 8 loads into vec5 32 ones,because of handling of the alignment and stuff :/
<karolherbst>
not sure
<karolherbst>
I have no idea
<karolherbst>
all I know is, it doesn't work
<karolherbst>
also that one "error 32 ssa_5 = intrinsic load_ubo (ssa_0, ssa_241) (access=0, align_mul=4, align_offset=0, range_base=0, range=384)" is probably not great
<karolherbst>
as it's actually a vec9
<karolherbst>
but maybe the solution is to set better alignments
<karolherbst>
so setting align_mul=1 on a vec16 char load is probably not right
<karolherbst>
and should be align_mul=16
<karolherbst>
jenatali: ever looked into that part?
<jenatali>
align_mul=1 on a vec16 char load would be correct I think
<jenatali>
IIRC CL only guarantees alignment to the element size, not the vector size
<karolherbst>
nah, vectors have alignment of the full vector
<karolherbst>
arrays are aligned per element
<jenatali>
Ah yeah ok, you're right
<jenatali>
Then yeah unless it's a packed struct, a vec16 of char should have 16-byte alignment
<jenatali>
And you should be getting that from clang, through llvm and spir-v into nir
<karolherbst>
we should probably set it correctly because drivers like radeonsi are wanting to lower to 32 bit loads apparently
<jenatali>
Yeah our compiler stack does that too
<karolherbst>
mhh
<karolherbst>
wondering why I lose that information
<jenatali>
Meaning I've fought with this already
<karolherbst>
the pass is still bogus because apparnetly it would require a vec9 type
<karolherbst>
:/
<jenatali>
Though I do my alignment stuff while they're still derefs before I/O is lowered
<karolherbst>
mhhh
<jenatali>
Yeah sounds like there's some wrong assumptions about vector sizes
<karolherbst>
ohhh.. ehh
ppascher has quit [Ping timeout: 480 seconds]
<karolherbst>
huh
<karolherbst>
okay, that's on me I think
<karolherbst>
load_kernel_input has the correct alignment info at least
<karolherbst>
yeah...... it's my lower_input pass
<karolherbst>
okay nvm, it's all my fault then :)
ppascher has joined #dri-devel
ahajda has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
iive has quit [Quit: They came for me...]
yuq825 has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
lygstate has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
<lygstate>
It's looks like that @marge-bot are did the works in FIFO way, but I think it's better to do it in LIFO so that we can manually reschedule it just move the almost suceed job to it and cancel it's running job, that
kem has joined #dri-devel
<lygstate>
we maybe add a Marge-LIFO label for marge to recognize
<lygstate>
In normal case it's stil FIFO, once this recognized, schedule this job first
cphealy has quit [Quit: Leaving]
<daniels>
LIFO means that the first jobs in busy times don’t get scheduled for hours
<airlied>
it might be nice to have a force this job to the front for CI up/downs but it might have to be limited in use
<lygstate>
LIFO is for manually usage
<lygstate>
maybe add a user @marge-bot-lifo ?
<lygstate>
It's FIFO a circle and merged nothing
<tleydxdy>
marge-preempt?
kem has quit [Ping timeout: 480 seconds]
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
kem has joined #dri-devel
cphealy has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
lemonzest has quit [Quit: WeeChat 3.6]
heat has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
<clever>
i think ive identified why some 3d games are so darn laggy for me
<clever>
it seems like my gpu is only capable of doing a single 3d render at once? and the compositor has to wait its turn
<clever>
so if the game is running at 5fps, the desktop compositor is now also running at 5fps, and even discord suffers
Company has quit [Quit: Leaving]
sysescool has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
mbrost has quit [Read error: Connection reset by peer]
sigmaris has quit [Ping timeout: 480 seconds]
sigmaris has joined #dri-devel
bmodem has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
kem has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra is now known as Guest929
rsalvaterra_ is now known as rsalvaterra
Guest930 has quit [Ping timeout: 480 seconds]
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
sarnex has joined #dri-devel
<ishitatsuyuki>
Do we have any pass timing like infra within NIR?
rmckeever has quit [Quit: Leaving]
<ishitatsuyuki>
Trying to do some major ACO tweaks, and wondering if there is any existing effort to track fine-grained performance
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
kem has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
mhenning has quit [Quit: mhenning]
danvet has joined #dri-devel
Lucretia has quit []
jewins has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
Compy_ has quit [Remote host closed the connection]
frieder has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
mszyprow_ has joined #dri-devel
<tomeu>
flto: robertfoss: do you have a branch somewhere with drm/msm support for sm8350?
sravn has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
mszyprow_ has quit [Ping timeout: 480 seconds]
dcz_ has joined #dri-devel
fab has quit [Quit: fab]
aravind has joined #dri-devel
cailtb^ has quit [Remote host closed the connection]
shoragan_ has joined #dri-devel
shoragan is now known as Guest933
shoragan_ is now known as shoragan
tzimmermann has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
rasterman has joined #dri-devel
oneforall2 has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
oneforall2 has joined #dri-devel
<tjaalton>
tarceri: ack, thanks
jkrzyszt has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
tursulin has joined #dri-devel
swalker_ has joined #dri-devel
lynxeye has joined #dri-devel
swalker_ is now known as Guest936
swalker__ has joined #dri-devel
lynxeye has quit []
lynxeye has joined #dri-devel
mszyprow_ has joined #dri-devel
Guest936 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
<jani>
emersion: I guess there's a lack of system level view of Type-C connectors and how DP alt mode and other USB usage coexist. that said, I'm also not sure how exactly this helps. maybe for that, a userspace implementation of any kind would go a long way in explaining what this is to be used for
Guest933 has quit []
mszyprow_ has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
koneko has joined #dri-devel
aravind has joined #dri-devel
kov has quit [Quit: Coyote finally caught me]
kov has joined #dri-devel
<koneko>
Hi, apologies if this is the wrong place for this question. I'm trying to get vulkan working on a raspberry pi zero (bcm2835). I managed to narrow the problem down to /sys/dev/char/226:0/device/uevent (/dev/dri/card0) and /sys/dev/char/226:128/device/uevent (/dev/dri/renderD128) both having OF_COMPATIBLE_0=brcm,bcm2835-vc4 however in the code https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/broadcom/vulkan/v3dv_device.c#L1043
<koneko>
it's looking for a RENDER node with OF_COMPATIBLE_0 of brcm,2711-v3d. Anyone know if I'm missing something? Thanks
<daniels>
koneko: unfortunately you're missing hardware that can run Vulkan
aravind has quit [Ping timeout: 480 seconds]
<daniels>
koneko: the v3d driver only works on the SoC in the RPi 4 and above; earlier RPis use the vc4 driver instead of v3d, and don't have Vulkan
<koneko>
daniels: Ah, thanks so much, it looks like EGL/GL works so I guess graphics are possible but maybe not hooked up yet?
aravind has joined #dri-devel
<daniels>
koneko: yes, the vc4 driver will do EGL and GL, but you won't get Vulkan supported on that hardware
<koneko>
daniels: I see, thanks so much!
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
mszyprow_ has joined #dri-devel
March-123 has joined #dri-devel
mszyprow_ has quit [Ping timeout: 480 seconds]
<danvet>
jani, yeah since it seems to be from google the open userspace should exists, so maybe just a matter of adding the link to that gerrit change is missing?
<danvet>
unless this is done the wrong way round with kernel first and then userspace :-)
<danvet>
jani, also it seems incomplete because the usb side isn't included in the patch set?
<danvet>
and I guess last point, is this going to be cros exclusive because Too Hard for general x86 acpi platforms
<danvet>
the latter might put us into a nice backlight style mess (but imo that's not a blocker if it should at least in principle be fixable)
<danvet>
jani, so tldr; I think the issues here are all technical, and we're not even anywhere near "does this need open userspace or not"
lemonzest has joined #dri-devel
<jani>
danvet: may I ask you to respond on the list with authority, please?
srslypascal has quit [Remote host closed the connection]
<robertfoss>
tomeu: if you have a sm8350-hdk laying around. dont forget enabling the hdmi output using switch 7&8 of the rightmost dip switch package
<MrCooper>
clever: yep; the display server needs something like https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1880 to avoid that (it's sufficient only with direct scanout of client buffers though, for compositing it needs to use a proper high priority GPU context which can preempt lower priority ones as well)
JohnnyonFlame has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
<tomeu>
robertfoss: headless is fine for now, but thanks!
Compy_ has joined #dri-devel
<dcz_>
is it possible to use mesa in a prefix with just an extended LD_LIBRARY_PATH, or will it blow up?
<dcz_>
would glvnd interfere with that somehow?
<emersion>
dcz_: it is possible
<emersion>
you might need to set some other env vars
<tomeu>
do you know why and what would be a good source for using in mesa-ci?
<jenatali>
karolherbst: but I don't quite get why
<karolherbst>
"../mesa-9999/src/compiler/clc/meson.build:33:0: ERROR: File /usr/lib/llvm/15/lib64/clang/15.0.4/include/opencl-c-base.h does not exist."
<karolherbst>
gentoo is doing weird slotting
<karolherbst>
I fix it by requiring the need of having the files in the first place 🙃
<karolherbst>
wondering how that works out at runtime tho
<karolherbst>
fails at runtime tho
<jenatali>
Right, I don't think it makes sense to build it if it's not going to work
<flto>
tomeu: the reason its not in linux-firmware is that the a660 firmware was added for sc7280/chromeOS which doesn't run under qcoms hypervisor and doesn't need this crap
<tomeu>
hmm, I see
<tomeu>
not sure we should use a file in mesa ci that we don't know if we have a license to redistribute though
March-123 has quit [Ping timeout: 480 seconds]
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
fab has quit [Quit: fab]
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
<dcz_>
emersion: any idea why I miss some symbols in the prefix? symbol lookup error: /home/purism/cambuild/utils/crispy/conv/raw: undefined symbol: glEGLImageTargetTexture2DOES
<daniels>
dcz_: you need to use eglGetProcAddress for extension symbols
<HdkR>
libepoxy is a good library for doing that automatically for you :)
<dcz_>
weird that it worked before, but yeah, seems I'm using it directly
fab has joined #dri-devel
<HdkR>
dcz_: Different drivers may expose symbols incorrectly if you were testing against a different driver stack
<dcz_>
no, just 2 or 3 releases earlier
<HdkR>
Interesting, I guess someone hecked up
<jenatali>
That seems unlikely, given the symbol check test that runs in CI
<dcz_>
mesa 21.2.6
<jenatali>
Maybe a glvnd difference?
<HdkR>
At some point that glvnd default option change will get merged
<karolherbst>
gentoos handling of llvm/clang doesn't really work out for us
<karolherbst>
I know, I know, I don't want to be there either, but we need a solution one way or the other
darkbasic4 has joined #dri-devel
<mattst88>
I don't have any context why it doesn't really work for us—would you mind commenting and explaining?
<karolherbst>
sooo.. the issue is, that clang installs its files into /usr/lib/clang/$version/ and llvm into /usr/lib/llvm/$major_version/. So clang and clc search for opencl-c-base.h inside /usr/lib/llvm/$major_version/lib64/clang/$clang_version
<karolherbst>
it's a bit weird that gentoo installs llvm/clang that inconsistanly but I'm also not quite sure what's the actual "correct" way of dealing with this would be I think
<mattst88>
can you comment on the bug and try to explain?
<karolherbst>
yeah... I try... but maybe there is a less painful way of going about it... jenatali do you know if we have a proper API call to fetch the actual resource dir of libclang at runtime?
<jenatali>
No idea
<karolherbst>
super
<jenatali>
I've never tried to do it at runtime because runtime doesn't work for us, it needs to be embedded at build time
<daniels>
karolherbst: tbf Fedora also has /usr/lib64/clang/15.0.0/opencl-c.h, at least on my machine :P
<karolherbst>
yeah
<karolherbst>
but we load based on the llvm dir
<karolherbst>
and llvm dir is /usr/lib64 on fedora
<mattst88>
does fedora allow multiple llvm versions to be installed at once?
<karolherbst>
just this weird slotting gentoo is doing messes it all up
<karolherbst>
partly
<mattst88>
believe me, we'd love to not have to allow multiple llvm versions
<karolherbst>
yeah, it does
<karolherbst>
llvm$version-devel packages exist for like all versions
<karolherbst>
but I guess we should query the resource path at runtme somehow
<karolherbst>
that's a cursed path, but I guess if we could get that info it would be okay
<daniels>
karolherbst: I mean we'd just have to exec clang -print-resource-dir inside the Meson build
<karolherbst>
I'd rather not, but....
<karolherbst>
actually, I don't want to have the path at build time at all
<karolherbst>
*to
<daniels>
atm we do what upstream LLVM's CMake stuff does ($llvm_libdir/clang/$clang_ver/include), but I'd guess Gentoo have probably hacked CMake to deal with that too
<karolherbst>
maybe?
<karolherbst>
point is: I don't want to :D just let libclang figure it out. Why do we even have to tell clang where the stuff is.. oh right, because you could use something else or something something.d.sadhakjsdhkajhdwahdas
alyssa has joined #dri-devel
<jekstrand>
karolherbst: yes.
<alyssa>
eric_engestrom: Any objection to adding a Meson option to disable xmlconfig?
<jekstrand>
karolherbst: (RE: align_mul = 2 meaning things are 2B-aligned)
<jekstrand>
karolherbst: Assuming align_offset == 0, of course.
<alyssa>
eric_engestrom: Currently we hardencode WITH_XMLCONFIG=0 on android and windows, and WITH_XMLCONFIG=1 everywhere else
<dcz_>
is it that it doesn't get converted to float when in a shader?
<alyssa>
yep
<dcz_>
thanks. So I need to find a way to convince the driver to stop converting my R16 fourcc code request into R16_UNORM internally, but instead leave it at... R16_UINT
<dcz_>
I need to file a help request. I mean an issue :)
MrCooper has quit [Remote host closed the connection]
swalker__ has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
lstrano has joined #dri-devel
<danvet>
tzimmermann, I think there's a merge conflict between the nouveau pull and drm-misc-next fbdev_generic move that means nouveau doesn't built in the integration tree
<danvet>
airlied, ^^
<danvet>
I guess it'll go boom when the next drm-misc-next shows up?
<lynxeye>
dcz_: Something that should work on GLES 2 devices/drivers would be to import the buffer as RG88 and then sum up the r and g channel in the shader to fake 16bpc support. Though not sure how this would interact with texture filtering.
<dcz_>
lynxeye: yeah, I'm probably going to do that, but I wanted to try solve the problem the "right" way first
<dcz_>
then I have fewer quirks to support in the future
<danvet>
mripard, mlankhorst tzimmermann I put a fixup into drm-tip for the nouveau issue, pls include that in the pull request so airlied/me don't forget :-)
tursulin has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
Leopold has joined #dri-devel
Company has joined #dri-devel
Akari has joined #dri-devel
sgruszka has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
<mlankhorst>
danvet: too late. :p
<danvet>
mlankhorst, it's drm-next vs drm-misc-next
<danvet>
not fixes
<danvet>
so for mripard
<mlankhorst>
ah k
<mlankhorst>
Ah, I see
JohnnyonFlame has quit [Ping timeout: 480 seconds]
rgallaispou has quit [Read error: Connection reset by peer]
<tzimmermann>
danvet, thanks for helping out
tzimmermann has quit [Quit: Leaving]
darkbasic4 has quit [Remote host closed the connection]
<anholt>
alyssa: I've wanted to do something where we encode 00-mesa-defaults.conf in the driver binaries, and have XML parsing only for end-user configuration (and disabled on chrome os/android).
<jenatali>
anholt: That's how it works on Windows
<anholt>
it's the obvious sensible choice, to me.
<jenatali>
anholt: Oh, that's how it works on Android too :)
<jenatali>
xmlconfig.h, #define WITH_XMLCONFIG
<anholt>
right, so this already exists. just need to extend the static config case for the WITH_XMLCONFIG case and stop installing 00-mesa-defaults.conf.
<jenatali>
Yep
rmckeever has joined #dri-devel
<alyssa>
anholt: I would certainly ack that patch ;-)
<alyssa>
Is the XML parsing used on ChromeOS now?
<alyssa>
If yes, perhaps CrOS would want to disable it with thew meson option which I think I already agreed to add, whoops?
lynxeye has quit [Quit: Leaving.]
<alyssa>
So my question is why does Zink check WITH_XMLCONFIG itself when no other driver does
<alyssa>
going to assume that was a whoopsies and I can get rid of the #if and Zink-on-Android will work itself out
<jenatali>
Yeah that seems like a mistake
<jenatali>
Might've been from when xmlconfig was completely disabled on Windows rather than just baked in at build time?
<alyssa>
yeah I'd buy that
kts has quit [Quit: Leaving]
<alyssa>
honestly I have never touched a driconf file in my life
<alyssa>
IDK what users are putting in their files
<alyssa>
if anyone even is
<alyssa>
like, what would someone put in there that doesn't just belong in 00-mesa-defaults.conf?
<alyssa>
and if you do have such a bizarre use case, is compiling your own Mesa really prohibitively expensive?
<jenatali>
A workaround to play a game before it lands upstream and without having to build your own Mesa
<alyssa>
hrm
gouchi has joined #dri-devel
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
pa- has quit [Ping timeout: 480 seconds]
<anholt>
My view is that end-user driconf is basically a holdover from when there were lots of config knobs for low end hardware like "downconvert all my textures to lower precision because I'm desperate for vram space"
<airlied>
and we had the driconf application and we thought it could replace proprietary control apps
<anholt>
yep. trying to compete with that.
mbrost has joined #dri-devel
<alyssa>
before my time ..
<clever>
MrCooper: turning the WM compositor off also made the game way more responsive, despite not changing the fps much, i think every frame from the 3d engine was delayed by 2-3 frames
<clever>
the only thing i really use the compositor for, is alt+tab previews, and faster repainting on alt+tab
<kchibisov>
alyssa: I remember adding 'zero vram' option to prevent seeing garbage from apps not clearing stuff(even had this with some wm's showing green artifacts on window resizes). But it was 3-4 years ago under Xorg.
ngcortes has joined #dri-devel
<clever>
kchibisov: i have seen my windows wallpaper appearing on my linux desktop before, due to a lack of that
gildekel has joined #dri-devel
<alyssa>
the deed is done
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
ngcortes has quit [Ping timeout: 480 seconds]
<karolherbst>
I think it's finally time to merge !19381 and get the radeonsi MR into shape :3
Haaninjo has joined #dri-devel
Guest953 has quit []
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
Duke`` has quit [Ping timeout: 480 seconds]
dolphin has quit [Ping timeout: 480 seconds]
shankaru has quit [Ping timeout: 480 seconds]
aknautiy has quit [Ping timeout: 480 seconds]
elongbug has quit [Ping timeout: 480 seconds]
ybogdano has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
dcz_ has quit [Ping timeout: 480 seconds]
sysescool has quit [Remote host closed the connection]
sysescool has joined #dri-devel
bgs has quit [Remote host closed the connection]
<eric_engestrom>
jekstrand: in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19580 you tagged only the second commit for backport, but it doesn't apply without the first; should I backport both, neither, or let you do a custom backport MR? (I'm guessing "both" but this is your call)
<jekstrand>
eric_engestrom: Backport both
<eric_engestrom>
jekstrand: done :)
heat has quit [Read error: No route to host]
heat_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
danvet has joined #dri-devel
ngcortes has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
shankaru has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
dolphin has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
March-123 has joined #dri-devel
Cyrinux has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
enunes has quit [Ping timeout: 480 seconds]
krushia has quit [Quit: Konversation terminated!]
pzanoni has joined #dri-devel
aknautiy has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
gouchi has quit [Remote host closed the connection]
zf_ has joined #dri-devel
zf has quit [Read error: Connection reset by peer]
Haaninjo has quit [Quit: Ex-Chat]
<DavidHeidelberg[m]>
Playing with Tellusim StarWars demo at @0.2FPS . Got message it running at 6700TX at @330fps+. I have feeling that Intel TGL drivers has some room for improvements
<DavidHeidelberg[m]>
Thanks god it has also VK render, which runs at 2 FPS on my beloved Intel.
March-123 has quit [Ping timeout: 480 seconds]
<dj-death>
DavidHeidelberg[m]: yeah, we have a plan for this one
<dj-death>
DavidHeidelberg[m]: maybe next week
mirko has joined #dri-devel
<mirko>
'lo, i'm hacking on an imx6q based embedded system featuring a display, though, built in up side down. now i'm struggling with the seemingly simple tasl of transparently telling whatever subsystem in the kernel to rotate everything coming in via DRM/KMS by 180 degrees. i was hoping for some key i could use within the device-tree file but - while something like that was mentioned in
<mirko>
b60c1be747418a07fbe04f8533394a64b27b6181 - it doesn't seem to be honoured by imx6's ipu
<DavidHeidelberg[m]>
dj-death: cool cool, this trace would be great to have for regression/performance testing
dri-logg1r has joined #dri-devel
dri-logger has quit [Read error: Connection reset by peer]
<daniels>
mirko: userspace needs to rotate as well; Weston will do this based on the DT prop (via a KMS connector prop) but others may need explicit configuration
zf_ is now known as zf
<mirko>
daniels: i'm currentl using Qt and neither for the good old fb nor for the drm/kms backend they provide anything to rotate and i simply refuse to have to do it "in the application"
ngcortes has joined #dri-devel
<mirko>
but even telling Qt or further up the application layer in whatever way feels the wrong place. the upside-down situation is part of the hardware and shouldn't be dealt with in userspace