ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<karolherbst>
ehhhh
<karolherbst>
it becomes ugly
karolherbst is now known as karolherbst_
karolherbst_ is now known as karolherbst
<karolherbst>
zmike: so one issue is that with txl or txf zink probably can't rely on the samplers var to be of the correct dimension and I only have a stale image var one could extract that information from :(
<karolherbst>
and I see how annoying it would be to deal with that inside zink
<karolherbst>
but I honestly don't have a good solution here
<karolherbst>
anyway.. I pushed a few more fixes so all the other issues around that should be fixed
<jenatali>
karolherbst: I have a pass that converts the images into differently-typed variables based on how the image is accessed
<karolherbst>
in nir?
<karolherbst>
that would probably help quite a lot
<karolherbst>
I am getting very close to conformance "Pass 2309 Fails 24 Crashes 109" anyway. 80% fails are images stuff, others are random bits I am too lazy to fix yet
<jenatali>
karolherbst: yes, in nir
<karolherbst>
illwieckz: looks annoying.... and yeah... fast math probably is allowed to screw it up
<karolherbst>
jenatali: cool, how is it called?
<karolherbst>
and does it live inside mesa?
<illwieckz>
though the original code was calling for trouble
<illwieckz>
a = max(0, b); c = d / a; // meh
<jenatali>
karolherbst: not in front of a PC atm, but yeah it's in our compiler c file
<karolherbst>
okay, cool
<karolherbst>
I probably saw it at some point
<karolherbst>
illwieckz: heh.... though dividing by 0.0 is defined, not sure why the code would hick up on that though
Leopold has quit [Remote host closed the connection]
<illwieckz>
for some reasons it wrecked when multiplying the result of the divizion by zero
Leopold_ has joined #dri-devel
rsalvaterra has quit []
<karolherbst>
but inf * a == inf, no?
<illwieckz>
maybe…
<illwieckz>
if you think that's a bug you can tell LLVM guys it is :D
rsalvaterra has joined #dri-devel
<karolherbst>
but mhh
<karolherbst>
it's weird
<karolherbst>
so the min in your patch should definetly return 1.0 no matter what
<illwieckz>
yes
<karolherbst>
min(1.0, +Inf) is 1.0
<karolherbst>
so your patch shouldn't do anything really
<karolherbst>
but also not sure what pdfW is at runtime
<illwieckz>
also, what's fun is that for some reasons I was able to somewhat workaround the bug (but don't get the validated render, just avoided the glitches) by setting a scene parameter to 0
<illwieckz>
is it because 0/0 can be considered as 1 ?
<karolherbst>
yeah well.. if you mess with the parameters, the result changes :P
<illwieckz>
%)
<karolherbst>
0/0 is most impl defined I am sure
<karolherbst>
and probably either returns Inf or 0
<karolherbst>
cool.. I probably harvest that one and see if I can make it work with that
<jenatali>
Sounds good
<karolherbst>
though not sure it fixes the issue I am seeing atm
<jenatali>
I'm back to work tomorrow, lemme know if you have trouble
<karolherbst>
image stores all work
<karolherbst>
it's just txl/txf which is busted
<karolherbst>
but maybe I'll use that one to simplify the code for zink
<illwieckz>
for my knowledge, what are those intel clc and microsoft clc in Mesa for?
<karolherbst>
intel clc == raytracing
<illwieckz>
ah yes I remember some phoronix articles
<karolherbst>
ms clc == jenatalis hobby project :P
<illwieckz>
which is about? :D
<karolherbst>
implementing CL on top of d3d12, don't ask me
<karolherbst>
:P
<illwieckz>
okok :D
<karolherbst>
(though we might be able to nuke it with rusticl once we are competent enough and faster)
<illwieckz>
(don't say it too loud)
<illwieckz>
:D
<karolherbst>
we already talked about it on XDC
<illwieckz>
ah maybe
alanc has quit [Remote host closed the connection]
<illwieckz>
I wonder how it could be possible to re-release a luxmark 3.1+ build anyway
alanc has joined #dri-devel
<illwieckz>
I have many patches, including some fixing many crashes (like crashes happening when OpenCL compilation fail, or when a platform lists no valid devices)
<illwieckz>
plus this bug fix
<karolherbst>
I doubt they'd care as much. but dunno
<karolherbst>
next year there won't be only rusticl anyway
<illwieckz>
what do you mean?
<karolherbst>
nothing
<airlied>
hey I just fixed clover for llvm16 :-P
<illwieckz>
ooooh
<karolherbst>
ehhh
<illwieckz>
I have to try this with my patched luxmark =)
<karolherbst>
waste of time if you ask me
<illwieckz>
no, we need it to compare with rusticl :D
<karolherbst>
I'd rather compare with intel neo and ROCm
<karolherbst>
more ambarassing this way for them
<airlied>
karolherbst: possibly, but opaque ptrs warnings have to die :-P
<karolherbst>
sure
<karolherbst>
airlied: btw.. seen my benchmark against ROCm?
<karolherbst>
it ended exactly like everybody would have guessed
<airlied>
karolherbst: yeah interesting, though not sure how meaningful luxmark is in the "real" world
<illwieckz>
yeah but since clover was already faster than any amd driver on luxmark, I want to know how much rusticl is slower or faster compared to clover
* airlied
also isn't sure what the "real" world for CL is
<karolherbst>
probably a lot, as it's like pixmark_piano only testing actual kernel runtime
<karolherbst>
but...
<karolherbst>
I suspect that inlining might be the core part here
<karolherbst>
so if we stop inlining libclc, we might get the same perf hit
<illwieckz>
clover isn't inlining, right?
<karolherbst>
dunno
<karolherbst>
that's up to llvm
co1umbarius has joined #dri-devel
<karolherbst>
though not sure how the libclc integration works there
<illwieckz>
well, I doubt rocm is inlining, and rocm also uses llvm
<karolherbst>
airlied: I suspect once kernels use fma and other funky stuff rusticls performance will tank
<karolherbst>
but that's all fixable
<illwieckz>
I can compile and run microphone and hotel scene kernels on clover, not on rusticl
<karolherbst>
honestly.. there are sooo many low hanging fruits
<karolherbst>
illwieckz: yeah.. because clover hands everything over to llvm
columbarius has quit [Ping timeout: 480 seconds]
<karolherbst>
and it's up to llvm to decide what to inline and what not
<karolherbst>
anyway, we'll have to sort that function inlining out and it might or might not be a huge annoying mess for backends
<karolherbst>
we'll see
yuq825 has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<illwieckz>
on this card Clover is 41% faster than RustiCL
<illwieckz>
R9 390X*
<illwieckz>
though on R7 240 (Oland, GCN 1.0) RustiCL is faster as Clover is so slow it doesn't validate the image…
camus1 has quit [Ping timeout: 480 seconds]
<illwieckz>
anyway airlied, your patch work
<illwieckz>
also about luxmark, opencl and real world, except luxmark 3.1 is old and then using old luxcore version no one uses today, it's real world, as it's just using real luxcorerender with real luxcore scenes, LuxCoreRender being an alternative renderer for tools like Blender, and is actually used as it provides features Cycles doesn't have (more realistic)
JohnnyonFlame has joined #dri-devel
camus has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
<illwieckz>
lol, when trying Clover on RDNA 2.0:
<illwieckz>
fatal error: cannot open file 'install/share/clc/gfx1033-amdgcn-mesa-mesa3d.bc': No such file or directory
<illwieckz>
on this chip ROCm is 5% faster than RustiCL
<illwieckz>
(I don't have right now devices that can run both ROCm, Clover and RustiCL)
<Mangix>
illwieckz: hashcan run on it?
<ishitatsuyuki>
is that hashcat? and am I right that rusticl uses ACO for AMD? In that case, I think it's probably bottlenecked by the lack of handling of a few crypto-related instructions inside ACO
<ishitatsuyuki>
if rusticl means we actually get a use case now, you're welcome to take it and put it into a MR :)
<Mangix>
I know clover never supported it
<illwieckz>
if I'm right rusticl on radeonsi doesn't use ACO yet.
<ishitatsuyuki>
ah so it runs on gallium
<ishitatsuyuki>
then it might be due to the llvm roundtrip or something
<ishitatsuyuki>
theoretically they should be able to emit the same intrinsics
<illwieckz>
yes rusticl is running on gallium
<HdkR>
Just go rusticl->Zink->radv :)
caef^ has quit [Remote host closed the connection]
eukara has joined #dri-devel
anshuma1 has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
<karolherbst>
illwieckz: interesting
<karolherbst>
would have to look at shaders, but there could be silly reasons for it
<karolherbst>
isn't it the fen were hardware ffma is like 1/4 of hardware fmad?
<karolherbst>
anyway... I am still happy about the performance given I did literally 0 performance work on it yet
aravind has joined #dri-devel
dviola has joined #dri-devel
Duke`` has joined #dri-devel
<ishitatsuyuki>
does hashing use fma though
<ishitatsuyuki>
i thought it's all integer
<ishitatsuyuki>
I would be also surprised if LLVM didn't have a good cost model for it (in ACO we just lower to the faster one because it's permitted by the SPIR-V spec)
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
rknii[m] has joined #dri-devel
rknii[m] has left #dri-devel [#dri-devel]
camus has quit []
camus has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
ahajda_ has joined #dri-devel
tzimmermann has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
fab has quit [Quit: fab]
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
kts has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
fab has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
rasterman has joined #dri-devel
frieder has joined #dri-devel
MrCooper has joined #dri-devel
kts has quit [Quit: Leaving]
mvlad has joined #dri-devel
reductum has quit [Remote host closed the connection]
reductum has joined #dri-devel
vyivel has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has joined #dri-devel
kts has joined #dri-devel
<pq>
karolherbst, FWIW, I'd expect 0/0 to be NaN if anything. No idea of your context, though.
i-garrison has quit [Ping timeout: 480 seconds]
vyivel has joined #dri-devel
lemonzest has joined #dri-devel
bl4ckb0ne has joined #dri-devel
jfalempe has joined #dri-devel
tursulin has joined #dri-devel
mattst88 has quit [Read error: Connection reset by peer]
mattst88 has joined #dri-devel
swalker__ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest3284
warpme___ has joined #dri-devel
swalker__ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
pcercuei has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
ella-0_ is now known as ella-0
ppascher has joined #dri-devel
vliaskov has joined #dri-devel
<emersion>
jadahl: hm my DP-MST setup doesn't work anymore so i can't test the patch…
itoral has quit [Remote host closed the connection]
tvc has joined #dri-devel
ced117 has quit [Ping timeout: 480 seconds]
anshuma1 has left #dri-devel [#dri-devel]
tvc has quit [Quit: Leaving]
JoshuaAshton has joined #dri-devel
i-garrison has joined #dri-devel
Guest3284 has quit [Remote host closed the connection]
fahien has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
chip_x has joined #dri-devel
fahien has joined #dri-devel
kxkamil has joined #dri-devel
chipxxx has quit [Ping timeout: 480 seconds]
sarnex_ has joined #dri-devel
sarnex has quit [Read error: Connection reset by peer]
fab has quit [Remote host closed the connection]
fab_ has joined #dri-devel
fab_ is now known as Guest3303
kts has quit [Quit: Leaving]
<illwieckz>
karolherbst, also, not only the speed isn't bad, but rusticl looks to support more hardware than any OpenCL driver for AMD (including Clover) %)
<karolherbst>
pq: mhhh... the question is rather, is that defined or can implementations do whatever
<pq>
heh, no idea
Leopold_ has joined #dri-devel
<jenatali>
karolherbst: for CL 0/0 is definitely NaN. That's a core IEEE floating point rule I'm pretty sure
<kisak>
from memory, I think it was something like: please get along with others and have approximately a couple dozen commits to mesa under your belt.
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
elongbug has quit [Remote host closed the connection]
Guest3307 has quit [Ping timeout: 480 seconds]
<jenatali>
Yeah reporter status I don't think has any requirements though, just getting someone capable to do it for you
<Compy_>
Got a bit of an odd issue in buildroot with kernel 5.19.16 and mesa 22.1.6. (using KMSDRM) The display doesn't seem to automatically start on boot, even with launching a tty on the tty1 (which should be the HDMI output). Similarly, if I launch an SDL2 application with a kmsdrm driver, it fails until I run "kmscube", which then kickstarts the HDMI output and runs correctly. I can then log into the console via serial, kill
<Compy_>
the kmscube process and run SDL2 stuff just fine. The only debug log entry that's different between the 2 SDL runs is "DEBUG: Failed to find index of mode attached to the CRTC. No connected displays found". Anyone run into similar symptoms? Target is an Allwinner H3/Mali400.
<Compy_>
Also, all kernel modules are statically loaded. There are no differences in `lsmod` output between runs
ced117 has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
<enunes>
Compy_: I don't think that should happen with H3, I'd suggest try to reproduce with a popular distribution, then if the problem is not there you can try to find differences between that and your buildroot setup
<Compy_>
enunes: Yeah, it doesn't happen on other distros. I'll start with the DTS and associated parameters and work down from there. Thanks a ton :)
<pq>
Compy_, wild guess: could your kernel be missing some drivers or fbcon support? SDL might be buggy to assume that there always is a mode set already.
<pq>
...drivers mostly for the firmware framebuffer handling
<Compy_>
pq: Possibly. According to dmesg, lima is initializing on boot. SDL's driver is set to kmsdrm
<Compy_>
`lsmod` both before and after are empty as all modules are statically compiled in.
<pq>
neither of those is an actual display driver
Surkow|laptop has joined #dri-devel
<javierm>
Compy_: do you have DRM fbdev emulation enabled ?
Guest3303 has quit []
<Compy_>
javierm: Wow, that could definitely be it. It wasn't enabled. Doing a quick build. Yeesh, can't believe I missed the complete lack of framebuffer device.
<javierm>
Compy_: yeah, been there done that :)
<pq>
I do think it's an SDL bug that it doesn't work in that case.
<javierm>
pq: yes, agreed on that
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Read error: Connection reset by peer]
JoshuaAshton has quit [Read error: Connection reset by peer]
<Compy_>
pq, javierm: Enabling drm_fbdev_emulation fixed both issues indeed. I have the display automatically starting, SDL2 also runs on the first try.
<Compy_>
Agreed on the SDL2 bug probability.
<Compy_>
javierm: Again, thank you so much.
Haaninjo has joined #dri-devel
yuq825 has quit []
<javierm>
Compy_: you are welcome
sdutt has joined #dri-devel
fab has joined #dri-devel
Major_Biscuit has quit []
<jadahl>
emersion: have tested the patch now, it works, the connector disappears after the modeset
<emersion>
cool
<jadahl>
but MST seems a bit "flaky". at one point the monitor just didn't light up despite KMS was configured to turn it on
<jadahl>
worked fine when I tried to reproduce though so ...
MajorBiscuit has joined #dri-devel
kts has joined #dri-devel
chip_x has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.6]
jewins has joined #dri-devel
MajorBiscuit has joined #dri-devel
iive has joined #dri-devel
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #dri-devel
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
frieder has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
<jadahl>
emersion: fwiw, what I tested was with the old patch reverted and the one you pasted applied
<emersion>
yup, sounds good
<emersion>
well, let's send this and see
orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
<jekstrand>
karolherbst: We only need one image, I think, as long as we use SPIR-V 1.6
<karolherbst>
mhhhhh
<karolherbst>
did they relax the req there?
<jekstrand>
karolherbst: The req is that they have to match but 1.4 adds SignExtend and ZeroExtend image operands which override the extension behavior.
<agd5f>
but a recent mutter bug causes mutter to eat up all of GTT memory and then the whole thing comes crashing down. Limiting GTT is sort of dubious workaround if you ask me. I don't think it really addresses the root cause and prevents most modern games from working
<danvet>
agd5f, I'm not entirely sure
<danvet>
from the discussions it sounds a bit like just slowing down ttm memory usage enough so that memory reclaim can keep up is enough
<danvet>
which is the old "ttm doesn't have a shrinker" problem
<danvet>
if you have a mm shrinker, then that will make sure you slow down synchronously
<danvet>
or well, more synchronously
<danvet>
which then will slow down whomever is wasting so much memory
<danvet>
but ckoenig implemented all that and then ripped it out again frm drm-misc-next because of some issues
<danvet>
but yeah my first guess isn't so much that this is a tracking issue, but the old "ttm doesn't have a shrinker" issue
<danvet>
and yeah fully agreed gtt limiting is just duct-tape here
fahien has quit [Ping timeout: 480 seconds]
<danvet>
agd5f, more high level, linux memory reclaim does not need you to associate allocations with applicatinos
<danvet>
that's only needed when you want to more actively manage it with cgroups
<agd5f>
danvet, and the OOM killer
<danvet>
all you need is a) a shrinker which b) eats synchronously into your active memory
<danvet>
b) can be delayed until higher shrinker levels a bit because otherwise the stalls are terrible for interactive use
<danvet>
agd5f, well if your shrinker reclaims synchrnously it will slow down whomever is allocating so much stuff
<danvet>
so exactly like the gtt hack, except adaptive to your actual memory pressure
<danvet>
needs some tuning probably like you allow a certain amount of memory to be reclaimed non-blocking by just queueing up the pipeling
<danvet>
but eventually you need to block in there on trying to free some gpu memory
<danvet>
which will then stall on gpu jobs
<danvet>
which should slow stuff down exactly how you want it to until we get out of the bind
<danvet>
or untile you're truly out of memory and something gets nuked by the oom killer
<danvet>
agd5f, or maybe I'm just not understanding stuff :-)
JohnnyonFlame has joined #dri-devel
<agd5f>
danvet, no that makes sense. I think I was confused due to a side conversation I had had with ckoenig
<danvet>
agd5f, I mean we do absolutely want cgroups and correctly associating all that memory with apps too, don't get me wrong
<danvet>
but from reading that bug I /think/ that's not exactly what's going on there
<zackr>
karolherbst: yea, but i don't see anything that's building piglit and uploading it. piglit itself is building containers to build piglit, so registry.freedesktop.org/mesa/piglit/debian/bullseye-slim:2022-09-11-add-isort is debian with mingw to build piglit but not the actual built piglit
<mdnavare>
agd5f: Hi Alex, I wanted to understand a bit more on how AMD open source driver shares code between windows and Linux and still uses the DRM core? Any blogs or articles you can point me to or could you briefly explain
<jenatali>
Ugh
<agd5f>
mdnavare, we only do for the core code in DC.
<mdnavare>
agd5f: So the sharing is only for the core mm code (only for gem/ memory management pieces) ? There is no code sharing for the display driver?
<agd5f>
the code was design with two parts in mind, a display manager (in drivers/gpu/drm/amd/display/amdgpu_dm/) which handles the interactions with OS. and the DC core (everything else in drivers/gpu/drm/amd/display/) which is mostly just programming sequences
<agd5f>
so the display core code is the only thing we share across OSes
<agd5f>
the display team has a whole process to handle patch review and tree maintainence for both incoming and outgoing patches
<agd5f>
hwentlan_, ^^^
* alyssa
blinks
<alyssa>
that explains so much
<agd5f>
mdnavare, the display code is the only place we share code.
<agd5f>
well that and amdvlk on the userspace side
mvlad has quit [Remote host closed the connection]
<mdnavare>
agd5f: So the DRM core that Linux display driver uses interfaces with amdgpu_dm since that will be separate for Linux and different DRM core equivalent for Windows? And then whats shared between Windows and Linux would be all in DC core which would be all HW specific prog sequences?
<agd5f>
mdnavare, that's the idea.
<mdnavare>
agd5f: And that helps shield against any uAPI changes since the shared DC core still completely uses the Linux DRM core
<mdnavare>
Also is the DC core that is shared all MIT licensed or GPL?
<agd5f>
MIT
* airlied
doesn't encourage anyone else to go down that road, DC interactions with atomic modesetting are not spectacular
<mdnavare>
agreed airlied, we just need to convince the same here internally to the management
<alyssa>
mdnavare: i'm so sorry
<airlied>
mdnavare: by all means write atomic core code and make windows deal with the impedance :-(
<alyssa>
giggle
rsjw has joined #dri-devel
<mdnavare>
airlied: Yes I think thats the direction we nede to convince them to take
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Frogging101>
This is Teardown, running in DXVK. Xwayland. In the map view, dragging the map with the mouse will occasionally send what I assume is a bad position
<Frogging101>
And the map will be thrown to the bottom left. I have also had the map thrown to the top left or top right
<Frogging101>
This only happens on kwin_wayland. Does not happen on X11. Have not tried GNOME. I observe something similar in Halo 3: ODST (Master Chief Collection)
<Frogging101>
For both games, It only happens in the map view, I see no evidence of bad inputs when in first-person view.
<Frogging101>
It's hard to pin down to a specific set of circumstances. It affects some games but not all games and only, perhaps, when the cursor is visible
<Frogging101>
I don't see anything amiss when I try to use "xev"
JohnnyonFlame has joined #dri-devel
ybogdano has joined #dri-devel
fab has quit [Quit: fab]
slattann has quit [Ping timeout: 480 seconds]
<Frogging101>
flibitijibibo: The above might be of interest to you. I don't think the game uses SDL but I think you know stuff about input
<flibitijibibo>
does SDL_VIDEODRIVER=wayland behave any differently?
<Frogging101>
It's a DXVK game
<flibitijibibo>
oh, thought it might have been using -native
<Frogging101>
Factorio uses SDL and is native, but it does not exhibit this whether I use SDL_VIDEODRIVER wayland or x11
<flibitijibibo>
i wonder if warp emulation has anything to do with it? we actually just recently added warp emu to SDL so this may at some point affect us too
rasterman has quit [Quit: Gettin' stinky!]
<flibitijibibo>
judging by the video, yeah i wonder if there's a frame where fake warping sends like a delta from the center to 0,0 (or the inverse)
<Frogging101>
actually Factorio is still running as an X client even with SDL_VIDEODRIVER=wayland, but I digress
Duke`` has quit [Ping timeout: 480 seconds]
<Frogging101>
flibitijibibo: What code would be doing fake warping if SDL is not being used?
<flibitijibibo>
i guess it would be however X applications warp the cursor, whether its calling X directly or winex11.drv, not sure if that's something xwayland does or if the compositor does something special for xwayland clients
<Frogging101>
I don't think the game is warping the cursor here though, because in the map view the cursor is visible and you drag it around by clicking and dragging
ella-0 has left #dri-devel [#dri-devel]
<flibitijibibo>
well it might not _always_ be warping, that might actually be the issue
chipxxx has joined #dri-devel
<Frogging101>
Is there a way to tell if the game is trying to warp the mouse?
<flibitijibibo>
i guess you could try to sniff around for calls to XIWarpPointer/XWarpPointer :shrug:
<Frogging101>
Since mouse acceleration will be compromised
<flibitijibibo>
i'm not entirely sure - i didn't get a chance to try this too much, all my stuff have relative mouse support so this was a "well, if the source guys are happy with this patch..."
<flibitijibibo>
my guess is sdl20-compat will have a quirks system like sdl12-compat just added, that might end up being one such case they check for
<Frogging101>
I can't actually run Portal 2 with SDL_VIDEODRIVER=wayland, I get a "SDL_Init failed: wayland not available"
<flibitijibibo>
probably isn't built into the SDL binary they ship