Falcon BMS on GNU/Linux
-
Shameless plug:
https://github.com/opentrack/opentrack
Builds and runs fine under Linux with TrackIR emulation.
-
Looks promising. I’ll give it a try, thanks
Regards,
Eduard Huguet -
Quite frankly, I don’t like the kernel module approach you chose. It’d be better to do a userland driver, stability-wise. Especially if you parse XML and do other fancy stuff. Look at xboxdrv, there’s some overlap and it’s done pure-userland.
-
Quite frankly, I don’t like the kernel module approach you chose. It’d be better to do a userland driver, stability-wise. Especially if you parse XML and do other fancy stuff. Look at xboxdrv, there’s some overlap and it’s done pure-userland.
Hi,
Thank you very much for your feedback, I really appreciate it. As for the comments you do, first of all let me make clear that the XML parsing is not done at all at kernel level, that definitely would be a very bad idea. This part is handled by the helper C/C++ library, which is used by the userspace tools. The assignments are then loaded into the driver using a fairly simple IOCTL-based API, similar to that of standard joydev module. The kernel module does some “fancy” things, as you put it ;), but definitely nothing very complicated.As for the userland vs in-kernel model, let me explain why I choosed the second path: when I started the project, I tried first the userland way, by implementing a daemon that read events from the joystick (using joydev’s standard JS API), then inject mouse & keyboard events into graphical stack by using XTEST X server extension. Although this part mainly worked, it had a main drawback, which is the impossibility to deny the target game (or program) the access to the source joystick event that originating the event. I mean, not all games allow you to “deassign” a button or an axis so it does nothing on the game, so if you program a button to issue a keyboard shortcut when it’s pressed, you can’t stop the game from performing also the action it had assigned internally to that button, in addition to the programmed shortcut’s one. IMHO, this was a serious limitation.
Instead, by implementing a a kernel-level filter you do have a very early access to the events sent by the joystick driver, in fact right before joydev itself receives them, and you have the ability to filter them out and generate your own from an internal virtual input generator. That renders the kernel approach very powerful, as you can map a button event to a shortcut without userspace ever knowing about the original event.
Regarding xboxdrv (a project I wasn’t aware of, frankly, but I’ve been thoroughly reading the documentation so I could at least know how it is implemented) it uses a different approach, which is directly reading RAW device data sent through libusb, then mapping source events to generated events that get injected through uinput extension (a kernel extension that allows to inject events into kernel input subsystem from userspace). Although it seems a valid approach, IMVHO it might have some flaws:
- It needs to decode the RAW data sent by the device, which is something that should definitely be done by the low level hardware driver, not from userspace. The input subsystem in Linux kernel is very cleverly designed, so all input devices transform the data sent by the hardware into a “normalized” set of events, so userspace does not need to know about device specifics. By re-doing this from userspace, your are definitely going an step back.
- I can’t clearly see if you can “hide” original events sent from the joystick. I suspect you can’t, as it suggests you to remove the “/dev/js0” created by joydev module so your game use the one created by xboxdrv. Again, this doesn’t look very good…
- It’s limited to USB devices. OK, this might not be an issue, as most game devices available are USB, but still.
That said, there are things I like from it, like the fact they use “uinput” to inject the events from userspace. This is something definitively worth looking at it, as I could take part of the mapping code out from the kernel and move it to userspace, but I’m sure I’d still need to use kernel module in order to provide the low level filtering.
Anyway, the approach used by JSMapper renders it quite universal, as it operates on the “normalized” set of events injected into the input subystem, so it didn’t need to care about any device specifics, it should work out-of-the-box on all of them. Obviosly, there still a lot of work to do, specially on the userland side, like i.e. providing a graphical UI to load profiles into the driver, or even a graphical UI to create profiles so you don’t need to mess around with XML format.
Hope this helps, and don’t hesitate to contact me if you have any other question
Kind regards,
Eduard HuguetPS: and sorry for the lengthy post…
-
How’s your ioctl API? Do you bound-check userland-passed pointers correctly? Is there a need for locking, and if so, do you follow kernel API?
As for xboxdrv, you missed the evdev interface. It’s confusingly both an XBox gamepad driver and a mapper for evdev, well, events. Try the latter to see how to do it in userspace.
I assume you can hide access through exclusivity level in xboxdrv. It’s possible to deny usage of the original device. If the game has hardcoded js0 input (doubtful!), try playing with udev for specifying which device should be named js0.
It’s not limited to usb, everything with evdev-compatible works.
Another problem is kernel ABI breakage, unless you want your code merged, you’ll struggle a lot, experience crashes, etc, as whoever’s in charge of the kernel’s subsystem breaks the API/ABI. Only userland API is stable.
-
How’s your ioctl API? Do you bound-check userland-passed pointers correctly? Is there a need for locking, and if so, do you follow kernel API?
As for xboxdrv, you missed the evdev interface. It’s confusingly both an XBox gamepad driver and a mapper for evdev, well, events. Try the latter to see how to do it in userspace.
I assume you can hide access through exclusivity level in xboxdrv. It’s possible to deny usage of the original device. If the game has hardcoded js0 input (doubtful!), try playing with udev for specifying which device should be named js0.
It’s not limited to usb, everything with evdev-compatible works.
Another problem is kernel ABI breakage, unless you want your code merged, you’ll struggle a lot, experience crashes, etc, as whoever’s in charge of the kernel’s subsystem breaks the API/ABI. Only userland API is stable.
Hi,
Yes, I do check parameter boundaries, and yes, I do use spinlocks / mutexes wherever is necessary, of course. I used joydev implementation (which I assume rock-solid) as a base for my module. I’m not saying I’m absolutely sure there is no bugs, but obviously if there are they will be fixed. If you are interested, check jsmapper_api.h file in src/linux/drivers/input folder.With regards to API/ABI breakage…, well, shit happens. I’ve been developing software for more than 20 years now, in multiple platforms (including Windows, Linux and embedded devices), and I’ve had to deal with that multiple times. Sooner or later, a library or a framework or something you rely on decides to make a fundamental change, and you need to deal with it and adapt your code. Again, shit happens. As for Linux kernel, it’s a known fact that 3rd party drivers must deal with kernel modifications, and that kernel modules needs to be compiled against every specific kernel for it to load the module. Distros provide mechanisms to deal with that (akmod, etc…) so again, no big deal here.
Merge the code into the kernel will be fine, but I’m not sure this projects fits into the general kernel. A possibility would be to merge it with existing _joydev _module, thus adding device programming to standard Linux joystick API. Anyway, this is something to discuss
in the future, not now probably.As a side note, quite recently I had to deal with an API change in the kernel, specifically the way in which char devices are registered, which got change in 3.8 version. I did have to adapt the code so it would compile against new kernels, while maintaining compatibility with old code but, again, it was no big deal.
And regarding xboxdrv: yes, I did read about the evdev interface, which I guess helps providing compatibility over any input device connected, but this doesn’t solve the (to me) fundamental problem of how to avoid the target game receiving original events from the device. Yes, you can mess with udev and so, but that renders things a little complicated.
The advantage of JSMapper is that the regular ‘js0’ joystick device will still be there, and the game will use it in a transparent way (JSMapper creates a different device the controlling API). It just won’t get the events that get filtered by JSMapper, instead it will receive keyboard events just as if it had been entered on the real keyboard.
Kind regards,
Eduard Huguet__ -
The advantage of JSMapper is that the regular ‘js0’ joystick device will still be there, and the game will use it in a transparent way (JSMapper creates a different device the controlling API)
Is it that much better than returning EBUSY on open(2) js0, which xboxdrv does when using exclusive mode?
But perhaps this is different than my use-case (xboxdrv for mapping DX buttons > 31 and axes over 7 for Wine).
Good luck with your project, I was trying to save you the trouble of page faults in kernel mode But given you have twice the length of experience than I do, you most likely know what you’re doing.
I’m looking for testers of the Wine protocol for opentrack, a few revisions ago Project Evil (NPClient.dll and friends) was refactored and it’s hard to test in a VM without an actual game. Want to give it a try?
Can you map axes too? The Saitek x65 crapola comes with nine axes and one HID node…
-
The advantage of JSMapper is that the regular ‘js0’ joystick device will still be there, and the game will use it in a transparent way (JSMapper creates a different device the controlling API)
Is it that much better than returning EBUSY on open(2) js0, which xboxdrv does when using exclusive mode?
Mmmmh… That way you completely blocks game from accessing the device, and I didn’t want to do that. They way it’s done, with JSMapper the js0 is created normally and can get accessed by the app in order to access i.e. the axes, there’s no need to redirect it to a new, different js device. The app will detect the joystick in the usual way and use it, but it simply won’t get any event notifications for buttons that are mapped by JSMapper.
Good luck with your project, I was trying to save you the trouble of page faults in kernel mode But given you have twice the length of experience than I do, you most likely know what you’re doing.
I learned the hard way to issue a sync command before execution tests…
I’m looking for testers of the Wine protocol for opentrack, a few revisions ago Project Evil (NPClient.dll and friends) was refactored and it’s hard to test in a VM without an actual game. Want to give it a try?
Definitely yes! I simply need to find the time to install the required compile dependencies and play with it a bit. Is there any documentation out there about how to perform? Anyway, I have a very old & crappy webcam, so I don’t expect anything spectacular…
Can you map axes too? The Saitek x65 crapola comes with nine axes and one HID node…
If by mapping axes you mean assign actions to play when the axis is moved then yes, you can. It works by defining “bands” over the axis, which can get assigned to actions to be played. I got the idea from old Dhauzimmer’s drivers for Saitek X-45, a set of non-official drivers that definitely improved the software provided by Saitek in Windows.
Kind regards,
Eduard Huguet -
Nah, I mean creating axes in a new device, copied from the old one.
Required for head tracker itself:
opencv 2.4.3+, flandmark from git
Required for opentrack:
opencv 2.4.3+, libqxt, Qt 4.
CMake runs the setup process and will whine whenever something’s missing. I recommend using ‘cmake-gui’ in order to set up Wine support et al.
Better yet, skype me at sthalik or email [email protected] if you run into issues. I’m chatty enough
-
Hello guys,
one of the only things that stops me from going into Linux is Falcon. I wish to ask you what is the process of running BMS on UBUNTU for example. I’m not very experienced with Linux so keep that in mind. I also want my TIR4 with clip to work and I use the MSS2 Joystick. Can someone give me a guide for what I need to do? this thread is full of advice but I need something more full.
Thanks,
RF -
Hi,
The easiest approach is, for what I know, to install PlayOnLinux, a Wine frontend that really excels at helping user to install Windows programs and games under Linux. Until very recently, modern Falcon BMS didn’t work under Wine, but it seems that finally now it does.Anyway, usual steps would be:
- Install PlayOnLinux as usual, through package manager (apt-get install playonlinux). That will bring Wine and related as a dependency.
- Open PlayOnLinux and use the “Install” button. In tha dialog, click on the “Install a non-listed program” link at bottom).
- Follow the steps to install the game: this usually involves creating a new virtual drive using Wine default options, then pointing to the F4BMS installer to install the game.
- Once installed, the game links will appear on the PlayOnLinux main screen, from where you will be able to launch the program.
As I posted in a previous anwser, only change I had to make in F4BMS config was to disable Triple Buffering, else I was getting a black screen whn entering the game simulation.
Regarding TIR4 I’m afraid I can’t help, as I don’t have the device. I don’t think it works under Linux, though. If I’m wrong, I hope someone will jump and correct me.
Finally, regarding the the joystick: in theory, it should simply work under Linux and you should be able to use it on the game without any major issues. If you like to “program” the device, though, you might want to try JSMapper (check my sig), which is a software I’m developing to make joysticks completely programmable under Linux. It works fine, but unfortunately I haven’t had yet the time to set up proper installation packages for it, so I’m afraid you’ll need to go the manual mode to install it, which might require some advanced skills…
Kind regards,
Eduard Huguet -
Maybe a TrackIR with software version 4 could run, because it do not need a special USB-driver, like version 5. (Me has a TrackIR-4, running with software version 5.xxx, that is the reason I know this).
Or one could try to install this special USB-driver for a TrackIR software version 5, so I think…I never tried this, because of some blackscreens by trying to run the sim under Wine and a following hard reset, which me and my computer do not like very much.
Greetings!
Earlybite -
I’m pleased to report that on open-source drivers:
OpenGL version string: 3.0 Mesa 9.3.0-devel (git-a77ee8b)
Falcon BMS works 4.32u6 with the exception of missing HDR rendering. It renders as if HDR was off.
There are no more CP stalls on CAYMAN 6970, same for broken shaders in newer shader models… It was a pixel/fragment shader, not the recently-optimized vertex shader that caused these errors, so credit goes to Mesa folk in all regard.
I’m going to ask some relatively friendly people over at WineHQ/CodeWeavers, as to what causes missing HDR rendering.
Would be very grateful if you guys pointed out it on your own in some way, e.g. whether old shader models miss HDR, as in:
fx_2_0 sm_2_0 sm_3_0
Is it fx_2_0 that only enables HDR or sm_3_0 has it too? Keep in mind that Wine/Mesa is years behind on OpenGL/D3D implementation support.
Even got my USB audio to work!
Edit: There’s still a GPU freeze which can be worked around by environment variable R600_HYPERZ=0
-
Update: HDR works and on Radeon 6970 renders 50-60 FPS in Basic Handling.
HDR didn’t work due to missing –enable-texture-float which is patented. It needs to be enabled for 32-bit Mesa, as BMS is a 32-bit app. That’s why the glxinfo program returned existing ARB_texture_{rg,float} but in BMS it didn’t.
-
Paging @hedgehog
gallium-nine is a new implementation of d3d9 as a Mesa3D gallium state tracker.
https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine
Did you try it? Does it even work on radeon on intel for you?
-
With following settings, I get 88 FPS in basic handling after pressing the ‘3’ key twice:
env vblank_mode=0 R600_DEBUG=nohyperz,nollvm,sb,sbstat
diff: dw:0%, gpr:-100%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-69%, gpr:-40%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-50%, gpr:-33%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-71%, gpr:-100%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:0%, gpr:-100%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-69%, gpr:-40%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-50libpng warning: Application built with libpng-1.6.6 but running with 1.5.13% , gpr:-33%err:menubuilder:convert_to_native_icon error 0x80004005 initializing encoder , stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-71%, gpr:-100%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% context diff: dw:-50%, gpr:-58%, stk:0%, alu groups:-75%, alu clauses: -60%, alu:-75%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:0%, gpr:-100%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-69%, gpr:-40%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-50%, gpr:-33%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-71%, gpr:-100%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:0%, gpr:-100%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-69%, gpr:-40%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-50%, gpr:-33%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-71%, gpr:-100%, stk:0%, alu groups:-100%, alu clauses: -100%, alu:-100%, fetch:0%, fetch clauses:0%, cf:0% context diff: dw:-50%, gpr:-58%, stk:0%, alu groups:-75%, alu clauses: -60%, alu:-75%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-26%, gpr:-66%, stk:0%, alu groups:-33%, alu clauses: 0%, alu:-33%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:4%, gpr:-50%, stk:0%, alu groups:20%, alu clauses: 0%, alu:5%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-36%, gpr:-66%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-56%, gpr:-88%, stk:0%, alu groups:-37%, alu clauses: 0%, alu:-62%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-10%, gpr:-60%, stk:0%, alu groups:0%, alu clauses: 0%, alu:-12%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-28%, gpr:-75%, stk:0%, alu groups:-50%, alu clauses: 0%, alu:-50%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:0%, gpr:-50%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:0%, gpr:-50%, stk:0%, alu groups:0%, alu clauses: 0%, alu:0%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:4%, gpr:-50%, stk:0%, alu groups:20%, alu clauses: 0%, alu:5%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-26%, gpr:-66%, stk:0%, alu groups:-33%, alu clauses: 0%, alu:-33%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-32%, gpr:-66%, stk:0%, alu groups:-37%, alu clauses: 0%, alu:-41%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:4%, gpr:-50%, stk:0%, alu groups:20%, alu clauses: 0%, alu:5%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-29%, gpr:-85%, stk:0%, alu groups:-37%, alu clauses: 0%, alu:-37%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-16%, gpr:-50%, stk:0%, alu groups:-20%, alu clauses: 0%, alu:-20%, fetch:0%, fetch clauses:0%, cf:0% diff: dw:-23%, gpr:-85%, stk:0%, alu groups:-28%, alu clauses: 0%, alu:-30%, fetch:0%, fetch clauses:0%, cf:0% context diff: dw:-23%, gpr:-64%, stk:0%, alu groups:-23%, alu clauses: -13%, alu:-29%, fetch:0%, fetch clauses:0%, cf:0%
The speedup is possible due to awesome work by Vadim Girlin (vadimg, mesa committer) who created the SB backend.
The code block is shader optimization amount. GPR for instance is the amount of registers Mesa uses with BMS shaders. Invididual shaders aren’t outputted in the list, though there are few of them. Each line represents one entry.
One day I’ll check with hyperz, but it used to crash…
HDR is on, pit shadows, high FOV, RedFlag by A.S. active. Previously only got up to 62 FPS in Basic Handling. The framerate doesn’t drop dramatically when viewing terrain, either…
OpenGL version string: 3.0 Mesa 9.3.0-devel (git-c4e6569)
Please keep in mind that proper multilib setup is necessary for Mesa!
–
HYPER-Z SUPPORT IS BROKEN!!! NOT JUST ME BUT ALSO HEDGEHOG GOT HARD LOCKUPS OF THE GPU DUE TO IT!!!
–
xorg.conf follows:
Section "Device" Option "EnablePageFlip" "true" Option "ColorTiling" "true" Option "ColorTiling2D" "true" Option "RenderAccel" "true" Option "AccelMethod" "EXA" Option "AccelDFS" "true" Option "EXAVSync" "true" Option "EXAPixmaps" "true" Option "SwapbuffersWait" "false" Identifier "Card2" Driver "radeon"
–
If anyone needs help, I’lm gladly offering it.
-
Apologies for YET another bump but this is fragging important!!!
On Linux, no pinning to cores necessary with kernel 3.9+. I’ve got constant 75FPS in basic handling without it!!!
My hypothesis - without ‘bouncing cow’ scheduling issue as on Windows, BMS works faster on Linux! That’s because it can use more CPU on flot when it matters, without affecting the software negatively.
Please consider adding pinning to threads, or using thread pools… So that Windows guys aren’t unhappy.
You have to take my word for it, but BMS worker thread on core zero remains there without bouncing around! This is fragging amazing.
-sh 20131009
-
Please help toolchain people:
12:16 <sthalik>=>0 0xf7469483 __strstr_sse42+0x303(s1="/bin/sh /home/sthalik/bin/falcon-bms.sh", s2="vtserver.bin") [/var/tmp/portage/sys-libs/glibc-2.18/work/glibc-2.18/string/../sysdeps/x86_64/multiarch/strstr.c:209] in libc.so.6 (0x7d77ca70) 12:16 <sthalik>1 0xf6eaee24 in libgl.so.1 (+0x60e23) (0x0032ed24)</sthalik></sthalik>
Looks like GNU CC is at fault for not inlining strstr_sse42!!!
I’m using gcc 4.7.3 and glibc 2.18
Any ideas?
–
https://sourceware.org/ml/libc-alpha/2013-08/msg00380.html
–
trying now glibc --disable-multi-arch
-
Please help toolchain people:
12:16 <sthalik>=>0 0xf7469483 __strstr_sse42+0x303(s1="/bin/sh /home/sthalik/bin/falcon-bms.sh", s2="vtserver.bin") [/var/tmp/portage/sys-libs/glibc-2.18/work/glibc-2.18/string/../sysdeps/x86_64/multiarch/strstr.c:209] in libc.so.6 (0x7d77ca70) 12:16 <sthalik>1 0xf6eaee24 in libgl.so.1 (+0x60e23) (0x0032ed24)</sthalik></sthalik>
Looks like GNU CC is at fault for not inlining strstr_sse42!!!
I’m using gcc 4.7.3 and glibc 2.18
Any ideas?
–
https://sourceware.org/ml/libc-alpha/2013-08/msg00380.html
–
trying now glibc --disable-multi-arch
Sorry, I don’t understand what you are doing. That seems some kind of stack trace from a Gentoo system, but I can’t see the relationship wifth Falcon.
What your script “falcon-bms.sh” does, exactly? What is “vtserver.bin”?Could you please ellaborate a litle bit more on the issue?
Kind regards,
Eduard Huguet -
vtserver.bin is, by a wild guess, some software that fglrx is applying kludges for, such as advertising different GL capabilities than what normally goes. It checks apparently argv[0] for its presence.
My script uses xboxdrv –evdev in order to use all 9 axes and more than 32 buttons on an X65. For Mesa, it also sets a few environment variables.
The issue is GNU glibc runtime CPU detection, i.e. the very presence of strstr_sse42 despite -march=x86-64 and the resulting unaligned accesses on sse42 code, which the caller doesn’t expect even to require proper alignment. GNU maintainers blame it on each other not the first time, gcc/glibc, gcc/torvalds, gcc/binutils… Instead of solving the issues.
I’ve disabled this so-called ‘mutliarch support’ and the problem is no more. I might switch back to Mesa now.
Thanks for your attention, guys!
To avoid bump, use:
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE
instead of the ‘all’ option, it sucks and causes OOM GPU breakage!
This is Mesa:
vblank_mode=0 R600_DEBUG=sb,sbstat,nollvm,nohyperz wine Falcon\ BMS.exe -window || true
Live Free or die!
–--------------
Linux launch script for BMS with X65:
1002 ~ % cat bin/falcon-bms.sh #!/bin/sh sudo -n xboxdrv \ --evdev /dev/input/by-id/usb-Saitek_Pro_Flight_X65_Control_System-event-joystick \ --evdev-no-grab \ --evdev-absmap ABS_#41=y1,ABS_MISC=x1 \ --evdev-keymap BTN_TRIGGER_HAPPY24=a,BTN_TRIGGER_HAPPY25=b,BTN_TRIGGER_HAPPY17=dl,BTN_TRIGGER_HAPPY18=dr,BTN_TRIGGER_HAPPY19=du,BTN_TRIGGER_HAPPY20=dd,BTN_TRIGGER_HAPPY31=x,BTN_TRIGGER_HAPPY32=y,BTN_TRIGGER_HAPPY33=tl,BTN_TRIGGER_HAPPY34=tr \ --deadzone 0 \ --dpad-as-button \ --trigger-as-button \ --silent \ & pid=$! cd '/home/sthalik/.wine/drive_c/Falcon BMS 4.32/Bin/x86' && vblank_mode=0 WINEDEBUG=-all R600_DEBUG=sb,nosbstat,nollvm,nohyperz wine Falcon\ BMS.exe || true sudo -n kill $pid wait $pid /home/sthalik 1003 ~ %