Berniyh

I kept my other devices connected specifically to test this and it worked fine for me first try. So I don't think that other devices being present was the problem. Maybe there was some other problem.

Just did a quick test earlier on and the FFB indeed works. I do have a problem with my rudder pedal though that I need to fix first, so couldn't yet do extensive testing.

I'm a Linux user since a long time, but gaming on Linux really wasn't an option a couple of years ago, because the translation from DX to OpenGL was a hit and miss. Actually, more a miss than hit, tbh. So trust me, I really want to get rid of DX and was very annoyed by the fact that it is by far the most popular API for rendering in games. However, with the appearance of DXVK, this changed, quite a lot. These days, you can try basically any random game that uses DX9-11, run it with DXVK on a Vulkan-capable GPU and it'll work in more than 90% of the cases just fine. Of course, there are problems remaining, but in most cases rendering isn't one of them anymore. That's how well this works. (Interestingly, DCS was actually one of the few cases where there were problems, since some textures on some maps seem to fail loading, i.e. remained black.) But ideally, everything is run via Vulkan, there is no debate there. I'm skeptical, when it comes to mods, because since these are usually done by people in their free time, you might drive people away by requiring them to learn Vulkan, meaning that maybe some neat ideas just don't get implemented, because the development overhead is too big. So, keep that in mind. Otherwise, I'm team Vulkan, all the way.

Actually, I see it the other way around. This kind of approach will get used more and more both on the software side as well as on the driver side. e.g. Intel already uses DXVK on Windows to get a working DX9 (10/11?) driver without having to implement one, because that's very complicated as well. (Actually, we don't know what they do exactly, we just know that DXVK is a part of it.) Look at it this way: DX drivers are very complicated and overloaded, hence the many driver-specific and also app-specific workarounds that you have flying around. VK drivers (and also DX12 drivers, since that's basically the same thing) on the other hand are pretty slim, there are way less driver-specific bugs to be expected. If you can now take one implementation of DX9-11 (i.e. DXVK) or OpenGL (i.e. Zink) on top of that, which is also better debuggable due to being open source, you could potentially avoid a whole lot of problems. The question "Who has the better graphics driver? AMD, Nvidia or Intel?" will become less relevant in the future.

It's quite funny to read that on a forum of a flight simulator, which requires you to read several pages of technical instructions (or watch a couple of videos), just to take off and fly. xD Can't you just run the server using Wine, too? I know that's what they are doing for other games that don't have a Linux version of the dedicated server.

Interesting read from an X-Plane dev: https://developer.x-plane.com/2023/02/addressing-plugin-flickering/ Short version: XP12 runs Vulkan for the main app, but plugins continue to use OpenGL, so they're bridging that. There are however issues with this on the driver side, it's not perfectly supported. So what they are doing now is to use Zink to translate the OpenGL calls into Vulkan and then execute these by the same Vulkan device that the main app is using. At least on Windows an Linux. They can't yet do it on Mac OS, because there is no Vulkan support there. (They are thinking about using moltenVK, which translates to Metal.) In my opinion, this is a really clever way to handle such a situation. Zink is an implementation of an OpenGL driver on top of Vulkan and is part of the open source Mesa driver stack that is the main OpenGL and Vulkan driver implementation on Linux. So you could run your average OpenGL game or application using Zink and a Vulkan driver. Now, so far this is not really relevant to DCS, however, there is also DXVK, which is a DX9-11 implementation on top of Vulkan. In contrast to Zink, it's not part of Mesa, it's a separate project, but it is open source as well. Even today you can use DXVK to just run DCS on a Vulkan driver on Linux. In the future, DXVK might be helpful to still let some parts run DX11, despite the main app being Vulkan; when performance is not limiting. Or e.g. for modding support, to avoid having modders write (more complex) Vulkan rendering paths.

Then it sounds like a DCS issue, will test tomorrow.

Yeah and by disabling all effects but one, you can find out which effects DCS uses. If your problem is happening using the in-game trim, then I'd guess that it's a DCS problem, since it means that DCS would tell the base to have zero force at a different position than you'd expect.

Ok thanks, that makes sense. I don't know how DCS implements FFB exactly. There are multiple ways to achieve FFB using different HID FFB effects: constant force, friction, damping, spring, sine wave, square wave, sawtooth and triangle (maybe more, but these are the ones I know of). For today's driving games, most of these are unused these days and instead you're mainly using the constant force effect. Of course the force is not constant, but you basically just give the joystick a force value to set (hence constant) which you then update continuously according to the physics. Other effects like spring (centering force) or sine wave were used in the past, but today the physics models are so refined that it's better to just calculate these effects in the proper physics model instead of faking it e.g. via the spring effect. (I think I've read that rFactor 2 uses the same method but not by using constant force but rather a sine wave force offset, without actually simulating a sine wave. Not sure why, but the important part is that all they are doing is just constantly updating the specific force they want the wheel to output.) Since the physics model in DCS is quite refined as well, in principle I'd expect them to do the same and use this method to simulate the proper physics, but I honestly don't know, could be different. The good thing is that you should be able to find out by activating/deactivating (or scaling) the specific effects. If they do, then I'd expect this to be a DCS problem, since all the base would be doing is just update the forces as they come in via the API.

@Abburoone more question: I see you have vJoy installed there. Is that required for the Brunner HID FFB interface to work? Or do you have it for some other reason?

Not sure what you mean exactly, but I'm pretty sure the CLS-E base is significantly bigger than the G940 base.

Ugh, those colors. xD Thanks for the info, I'll give it a go during the weekend. Will be interesting to see how it performs. Even though it's not really critical for me anyway, because I'm not look too much for effects, but trim is the only thing I really need and that worked already before (just not with the in-game functionality). Yes, it supports HID FFB, which is the standard that pretty much all other FFB joysticks should conform to as well. So any game supporting HID FFB via DirectInput should work now with the joystick. Including racing simulators, if you want to drive those with a joystick …

If you switch it to DirectX, which I guess should be rather called HID FFB(?), will that change be persistent or will you have to do it again every time after you turn on the device? Didn't yet have the chance to test it myself and even if, have to perform a FW update first (wanted to wait until they announce full HID FFB compatibility). The switcher trying to switch all devices sounds like a bug, did you report that to Brunner?

Supports DirectX FFB now: https://forum.brunner-innovation.swiss/forums/topic/directx-driver/#post-3001

Brunner just put a note out that they do now fully support DirectX: https://forum.brunner-innovation.swiss/forums/topic/directx-driver/#post-3001

The Monstertech frame is not supposed to even get close to the leather parts of the base. Underneath the leather is a metal plate. The Monstertech frame is supposed to be below that plate, as you can see in the picture I posted above. If you still have an issue, please post a picture of what you're doing.

By "wing" you mean the vertical parts that are stabilizing it? That should point down and then you put the stick in the frame coming from the top. If there is some other problem, maybe you should take a picture, because I really fail to see how this shouldn't work.

I've got one, but I think it's an older version. I think you need to screw it on from underneath, so that the Brunner's plate is on top. At least that's how it's done in case of the mount that I have. Edit: Mount the plate like shown here and then just put the Brunner in so that it sits on top. Put in the screws, tighten, done. Here is a picture with the joystick already mounted. It's the older mount plate that I have, but in the end it works the same way:

Maybe, but that was not the point.

I don't mean to rub this in your face. Ok, maybe a little bit. https://www.digitalcombatsimulator.com/en/support/faq/SteamDeck/ So indeed, they are now also targeting Steam Deck, which means targeting Proton/Wine. For those running Linux, this is big news. While they are still not officially supporting Linux (and possibly won't in the future as well, because Linux has so much more variety than the Steam Deck and most likely not natively), this should mean that at least they might pay attention that they are not breaking it either with new code. Something that was a bit problematic in the past, even though the game basically ran through Proton/Wine for the last 3 to 4 years. Anyway, not really want to start the discussion again, since I think we have all said everything on the topic, just wanted to leave this as an information here.

Yeah, FFB rudder pedals are mainly useful for dual-cockpit flight trainers, where they can ensure that the input matches on both sides. For home usage, you don't need them. For choppers, I think the VKB pedals are very nice. They are very precise and you don't need a lot of force to operate them. If you can live with the up/down movement and without toe brakes (most choppers don't have those anyway), then they are a good choice.

I don't use curves either. But as I said, it's of course down to personal preference. If you don't insist on using high forces, it might work out. Maybe someone here is using the CLS-E with an extension and can say more.

Depends on the amount of force you want to have and on what you're doing. Generally, the CLS-E is not great with extensions. Personally, I don't need an extension on the CLS-E, since it is already very precise, but that's of course personal preference.

The grip is optional for the CLS-P as well, it's stated in the description: [quote]Either the A320 Grip, the BRUNNER Jet Grip or an adaption of any customer-provided Grip is easily mountable.[/code] So if you want to use that with a Virpil grip, then they will make it work one way or another (if it is not already compatible). Reasons why you would choose the E are: price, size (that thing is really big and the cyclic version is even bigger), weight and possibly smoothness (according to the post you quoted. Personally, I haven't tried)

No, not of any frequency. You need a very specific set of at least three, but usually four states of which two are relevant for the actual laser wavelength (the other two are just for the pumping process to create the inverse population). Although we know many such sets for different atoms and molecules nowadays and although you can use advanced techniques like frequency doublers to access even more wavelengths, you can't create a laser for any frequency/wavelength.