For those interested in the latest big RPG from Larian Studios, here's my quick initial report on Baldur's Gate 3 running on Steam Deck and desktop Linux.
I might get it, I'm not sure. Some of the press info turned me off it. Like custom genitals and the bear sex. It just seemed unnecessary and strange. I don't do romance in games, so when it seems like there's special attention to it, it just kinda turns me off it. But, I do like fantasy rpgs. I played around 4 or 5 hours of divinity original sin 1 and 2. I really liked those, so maybe I'll get this since it seems like they're biggest effort yet.
Everything is optional and your choice. Don't romance anyone or do, your choice. Show genitals or don't, your choice. The Druid wearing a bear form is a choice too. This game is great because of all the choice and how many different outcomes a quest could have, or many different ways to solve a problem. Will I romance a guy wearing a bear form, no. But I'm glad it's there if others want to.
I'm old and it reminds me of the marijuana debate. I'll never smoke marijuana (I think all smoking is bad for you) but I don't care of other do. I'll vote to make it legal even though it's not for me. Why force my beliefs on others. Seems un-American.
Time to explore that camp I found just before bed last night.
I managed to use vulkan on nvidia on Arch, but needed to use Proton Experimental.
My 8bitdo gamepad shows up as two gamepads though with the same input :(
[Edit: apparently this is a problem with 8bitdo Ultimate Bluetooth in xinput mode using the USB 2.4ghz dongle. I had to turn off steam input for this game. It happens in some other games too)
I haven't played Baldur's Gate 3 myself, but one thing that might cause that:
Linux has two different joystick APIs. By default, at least on my Debian system, both drivers are set to load by default. The older API, joydev, creates a device at /dev/input/js0 (or some similar-such number). The newer one, evdev, will create a device at /dev/input/event0 (or some similar-such number).
You can use jstest to see devices via the joydev API, and evtest to see devices via the evdev API.
Some software uses libraries or the like that can talk to both and will expose both to the application. It looks like Baldur's Gate 3 doesn't have a Linux-native release, so I assume that WINE (well, Proton) will expose both as two gamepads.
This wasn't historically much of a problem, since it was something of a convention in software to not do anything with joysticks unless a gamepad was enabled in the game and the user configured the buttons (which was something of a pain in the neck, but whatever). Part of this was that there wasn't much of a convention as to which button number did what, which meant that it wasn't possible for a controller to work reasonably out of the box.
However, on Windows, the XBox controller kind of became something of a standard, and so software started assuming an XBox layout, and so using a controller out-of-the-box became more-common. There have been better ways to figure out what the layout is, as I understand it, but this kinda kicked software to make the jump to "be enabled by default".
Unfortunately, that meant that sometimes software didn't let one choose which controller to use, or let one manually configure the gamepad, or choose to ignore an attached gamepad, with the idea that the user was just going to dick it up.
So if you have a gamepad exposed as multiple gamepads, sometimes a software package will just try to be helpful and use input from anything that looks like a gamepad without giving you an option not to do so, which means that you get multiple events if you have multiple "virtual" gamepads being driven by one physical gamepad.
There may be better ways of addressing this -- I mean, there probably should be and maybe is a way of dealing with this in WINE, since there's no reason I can think of that you'd ever want to use joydev devices in software, like WINE, which can handle the evdev interface for a device. If a device is visible via both APIs, WINE should really only talk to it via evdev; Joydev is just kept around for compatibility with old software that can't talk to evdev. However, one way of solving the problem with a sledgehammer is just telling your machine not to allow use of the joydev driver. The evdev driver has been around for a long time. I don't personally know of any Linux game that doesn't support evdev; if there is, I'd guess that it's probably a pretty elderly, Linux-native, closed-source (either that or not getting very frequent updates) application. You can just blacklist the joydev driver, keep it from loading, and you'll only get the evdev device. That means that any software around that can only do the old joydev interface won't work, but I don't know of anything today for which that is the case.
On my Debian Trixie system, I have a file that does that (IIRC, because I ran into the same issue with Fallout 4, also via the WINE layer producing duplicate input, and with Fallout 4 not having the ability to ignore a gamepad at the application layer):
I created a file, /etc/modprobe.d/joydev-blacklist.conf:
# Gives duplicate events with evdev
blacklist joydev
Next boot, your Linux system will not ever load the joydev driver, and you won't get any /dev/input/jsX devices.
Arch looks to do things the same way; here's their documentation for blacklisting a module:
I tried blacklisting it, and that makes it no longer work in gamepad-tester (on html5), and still exhibits the same problem. I think this is just steam input being weird with this particular controller.
After the patch I tried Vulkan again and played for over 4 hours with out an issue. I'll play again...a lot over the weekend. We'll see if I have any issues.
Add comment