Jump to content
The simFlight Network Forums

Recommended Posts

Posted

I think I'll better try to live with these delays, as they are visible not on every device.

It seems to be the less evil, than not supporting 2 additional hats on the popular X52 joystick.

Also I can use the GUI part of my app to catch joybutton presses and send them to Lua script.. It will require to keep GUI running, but if it will be the only solution, I can live with it too.

One more question about HID lua library. Can you please check what is happening when I'm unpluging the device which is currently opened and polled in Lua. It seems that Lua library doesn't detect device removal and leaves some resources locked, until the whole FSX be restarted.

Posted

One more question about HID lua library. Can you please check what is happening when I'm unpluging the device which is currently opened and polled in Lua. It seems that Lua library doesn't detect device removal and leaves some resources locked, until the whole FSX be restarted.

Yes, that's quite possible. I never designed any of it for hot plugging/unplugging I'm afraid. I'd have to add more code for that. What would you expect to happen, just zero returns to all the calls?

Pete

Posted

I'm not sure, what I'm expecting :-)

It's just the same problem I have with my GUI app. It hangs up when I unplug any active device. It's not a big deal though..

But after all, lua script should not hang up on device removal (zero values will be good).

Also I see that CH Control panel hangs up too until I exit the FSX.

Posted

Correction.. there are two different events:

1. Pure device unplug

2. Switch device from Programmed to Direct mode in CH Control panel

My GUI hangs only on device mode change now.

And the lua part doesn't hang - the only HID- part of the script stops working. Other events like vriread countinue to work without a problem.

Posted

Correction.. there are two different events:

1. Pure device unplug

2. Switch device from Programmed to Direct mode in CH Control panel

My GUI hangs only on device mode change now.

And the lua part doesn't hang - the only HID- part of the script stops working. Other events like vriread countinue to work without a problem.

Sorry, I'm confused.

1. I have no idea if your "mode change" (whastever that is) is even detectable. Certainly unplug/replug is detectable. what is this "mode change"?

2. What is the HID part if not part of the Lua script? By "stops working" what do you mean -- no hang, no crash, only zero returns or something?

Maybe the mode change makes it report differently? Maybe it somehow closes and reopens the link, so you have to too?

Pete

Posted

Oh, sorry. I thought you know the CH devices logic. Forget about mode switching then... it's something like switching between pure hardware to software emulated modes. Ask Bob Church, if you really interested - he well describe it better.

From the HID library's point of view the device mode switching is like fast unpluging one device and pluging in another one on it's place.

As for Lua script hang ups... Ok. Script doing several things simultaneously. It handles the event.vriread calls, event.timer and some event.offset's. Timer event polls for updates all available HID devices in one loop.

Then if I unplug any of joysticks, all other joysticks stop working too. I think it's the com.readlast call stops working.

At the same time all other event handlers continue to work without any problems (vriread, timer and offsets monitoring).

Posted

Oh, sorry. I thought you know the CH devices logic.

No. I've not had any CH devices since way back in FS4 days. I've only got an MS Sidewinder Freestyle, a Saitek P3000 and a few GoFlight units. Stuff i keep around just for testing. All my real flying is done with PFC equipment, with my own drivers. They aren't joystick types at all.

Then if I unplug any of joysticks, all other joysticks stop working too. I think it's the com.readlast call stops working.

So, you mean it hangs? Or always returns null?

At the same time all other event handlers continue to work without any problems (vriread, timer and offsets monitoring).

Ah, so it can't be hanging.

Hmmm. I would need o be able to reproduce it, but I don't have time this week to write a multi-device Lua script I'm afraid. Maybe if you have a test one I can use to make it occur? If I can track it down I can fix it -- if it is fixable without closing and reopening devices.

Regards

Pete

Posted (edited)

Pete, you are taking it too serious. I was asking it from perfectionism point of view. I you don't have a quick answer for it, then just leave it. This is many times less important issue than the button delays. I cannot imagine that many of end users will ever face this problem. And even so, restarting FSX is not a big deal for those quite rare cases.

If you'll be interested some day you could install and test LINDA yourself to see how it behaves, but for now device unplugging issue is not really important.

And thank you for your great and instantaneous support on any question!

Edited by Artem Crum
Posted

Pete, you are taking it too serious. I was asking it from perfectionism point of view.

Ah, but I am a bit of a perfectionist too! I like things to work properly!

If you'll be interested some day you could install and test LINDA yourself to see how it behaves

Okay. Let me know when its available!

Regards

Pete

Posted

Pete, there could be another problem with HID library.

We are now doing the compatibility tests with different HID devices, and I've just found a possible problem. I'll try to explain but it will be hard for me... sorry :-)

Common joysticks are sending the only one HID report per cycle. One button press generates one portion of data sent to the driver. But there are some non-standard devices that sending two or may be more reports at once.

By report I meen that raw data packet from HID device which we need to decode/parse to get buttons and axises states from it.

As I can understand that is done for "economy" purposes. Device I'm talking about has 30 buttons, 6 8bit axises, 1 4bit Hat, but it's report length is only 7 bytes which is definitely not enough. That's why the whole device state is transmitted in the two sequential reports. First report brings data about Values (axises) and the next report -- about the Hat and buttons.

I've made changes to LINDA's GUI to make it work with these devices, but the Lua part of application seems doesn't work.

Can you, please, confirm if FSUIPC/HID Lua library could work with such devices?

Attaching two diagnostics reports about this device.

HidScanner:

  Device at "\\?\hid#vid_0417&pid_0130#7&2e740b48&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}"
  Vendor=0417, Product=0130 (Version 1.0)
  Manufacturer= b padt=0130 (Version 1.0)
  Product= usb pad
  Serial Number= b pad=0130 (Version 1.0)
  Usage Page: 1
  Input Report Byte Length: 7
  Output Report Byte Length: 0
  Feature Report Byte Length: 0
  Number of Link Collection Nodes: 2
  Number of Input Button Caps: 1
  Number of InputValue Caps: 7
  Number of InputData Indices: 37
  Number of Output Button Caps: 0
  Number of Output Value Caps: 0
  Number of Output Data Indices: 0
  Number of Feature Button Caps: 0
  Number of Feature Value Caps: 0
  Number of Feature Data Indices: 0
  Buttons range 1 -> 30 at indices 7 -> 36
  Value Thr at index 0, range 0 -> 255, using 8 bits
  Value Rdr at index 1, range 0 -> 255, using 8 bits
  Value Y at index 2, range 0 -> 255, using 8 bits
  Value X at index 3, range 0 -> 255, using 8 bits
  Value Z at index 4, range 0 -> 255, using 8 bits
  Value U/RX at index 5, range 0 -> 255, using 8 bits
  Value POV at index 6, range 0 -> 7, using 4 bits
  **************************************************************************

Note the Number of Link Collection Nodes: 2

Other similar tool:

	
"usb pad"  VID=$0417 PID=$0130
	UsagePage=Generic Desktop ($0001)  Usage=Joystick ($0004)  CollectionType=Application ($01)
		Button Input Range: UsagePage=Button ($0009) 1..30
		Value Input: UsagePage=Simulation ($0002) Usage=Throttle ($00BB)
		Value Input: UsagePage=Simulation ($0002) Usage=Rudder ($00BA)
		Value Input: UsagePage=Generic Desktop ($0001) Usage=Hat Switch ($0039)
		UsagePage=Generic Desktop ($0001)  Usage=Pointing Device ($0001)  CollectionType=Physical ($00)
			Value Input: UsagePage=Generic Desktop ($0001) Usage=Y Axis ($0031)
			Value Input: UsagePage=Generic Desktop ($0001) Usage=X Axis ($0030)
			Value Input: UsagePage=Generic Desktop ($0001) Usage=Z Axis ($0032)
			Value Input: UsagePage=Generic Desktop ($0001) Usage=Rotational X Axis ($0033)

Note the TWO-levels hierarchy and the second UsagePage. Usually there is ONE-level and ONE UsagePage per device.

This is the VRinsight MS/TT panel. And it works fine in FSUIPC Buttons&Switches panel. Also it's normaly detected by Windows as a generic game device with all buttons and axises working.

Posted

Can you, please, confirm if FSUIPC/HID Lua library could work with such devices?

I've no idea at present.

Note the Number of Link Collection Nodes: 2

Yes, but what does it mean? How do I select? And I've no such device to experiment with.

I've only managed o do what I have done by experimenting with devices using a USB debugging program I purchased for the purpose.

Note the TWO-levels hierarchy and the second UsagePage. Usually there is ONE-level and ONE UsagePage per device.

How are you interpreting the information you present to give you two and only a second "usage page"? Are you actually referring to "Usage= ..." not "UsagePage" of which there are many?

This is the VRinsight MS/TT panel.

Maybe they can be persuaded to send me one: they did send me one of each of most of their other devices. I'll ask. but it could be a few weeks even if it is okay -- they ship from Korea.

Regards

Pete

Posted

Mine current solution is not a solution but a quite dumb workaround. I didn't understand the logic of all this double UsagePages and so on. All I did is just simple debuging of reports comming from the device where I've found that there are two different reports coming one by one, and that the "buttons-report" is coming second on THIS PARTICULAR device.

Then I make handler to skip the first report for this device and only parse the second one by individual rules... But DirectInput seem to know The Secret about how to correctly decode such types of devices... :-)

BTW I don't have an access to this device too. Only some debug logs from LINDA supplied for me by beta-tester.

Posted

Then I make handler to skip the first report for this device and only parse the second one by individual rules.

Sorry, I'm confused. Is this with my Lua com library?

And another thing I don't understand. Looking at the device where folks are selling it it appears to ONLY have buttons and switches. 32 of them? Yet the report is only 7 bytes with these entries:

Value Thr at index 0, range 0 -> 255, using 8 bits

Value Rdr at index 1, range 0 -> 255, using 8 bits

Value Y at index 2, range 0 -> 255, using 8 bits

Value X at index 3, range 0 -> 255, using 8 bits

Value Z at index 4, range 0 -> 255, using 8 bits

Value U/RX at index 5, range 0 -> 255, using 8 bits

Value POV at index 6, range 0 -> 7, using 4 bitsThe buttons all follow in your second report which is logged by my program as:

Buttons range 1 -> 30 at indices 7 -> 36

"indices 7-36" here gives the position of those bits, apparently using the last 4 bits of the first 7 bytes and 26 bits in the second report. Right?

But 30 buttons for 32 buttons/switches on the device? where are the other 2?

And what are those Throttle, Rudder, Y, X, Z, U/RX and POV values for if it doesn't have such? It's a bit weird.

Anyway, I've asked if they can send me one. I'll let you know.

Regards

Pete

Posted

No-no, I'm talking about Delphi application. GUI for LINDA.

This GUI works with HID devices using it's own library.

But the main core of LINDA is the Lua script inside FSUIPC/FSX environment and uses your implementation of com/HID library.

Posted

Our replies are crossing. I added more to the last one so please re-read it for me. ;-) (Save me re-posting)

No-no, I'm talking about Delphi application. GUI for LINDA.

This GUI works with HID devices using it's own library.

Ah. So why do you need the rather inferior Lua library facilities. I can't hope to compete with "proper programming"! I wouldn't really want to.

But the main core of LINDA is the Lua script inside FSUIPC/FSX environment and uses your implementation of com/HID library.

But why?

Regards

Pete

Posted

There are two different devices MS panel and TT panel with different sets of controls, but both have the same hardware inside.

Buttons range 1 -> 30 at indices 7 -> 36

"indices 7-36" here gives the position of those bits, apparently using the last 4 bits of the first 7 bytes and 26 bits in the second report. Right?

I was thinking the same way but it is wrong. Second report starts with 4 bits for Hat and 30 bits from 5 to.. whatever for buttons... Don't understand the logic behind it.

And yes, it's totally weird :-)

Posted

Ah. So why do you need the rather inferior Lua library facilities. I can't hope to compete with "proper programming"! I wouldn't really want to.

But why?

First of all, I think you are much better programmer than me, and your code is better. I cannot call what am I doing the "proper programming". Scripting, yes. Interface building, yes. But the low-level system programming is not my best side.

And the second reason, that I don't want make users to run one more background application, where the FSUIPC/Lua can do it all.

Posted

There are two different devices MS panel and TT panel with different sets of controls, but both have the same hardware inside.

Aha! I see. Oh dear. I've asked for "an MS/TT Panel"! Oops!

I was thinking the same way but it is wrong. Second report starts with 4 bits for Hat and 30 bits from 5 to.. whatever for buttons... Don't understand the logic behind it.

I think maybe the HidScanner results are really only for the MS part.

And yes, it's totally weird :-)

I'll sort it, but I think I'm going to need one or both devices. Can you hold out with your interim solution?

Pete

Posted

I'll sort it, but I think I'm going to need one or both devices. Can you hold out with your interim solution?

Yes, certainly. There is no rush with it.

These panels are not so popular, and LINDA is still in closed beta-testing yet.

Posted

For some strange reason beta-tester just reported, that both of his TT and MS panels have started to work inside Lua without any changes done in Lua code...

One more weirdness. I've asked him to reboot and re-plug devices into other USB-ports and they are keep working anyway. :oops:

Posted

For some strange reason beta-tester just reported, that both of his TT and MS panels have started to work inside Lua without any changes done in Lua code...

One more weirdness. I've asked him to reboot and re-plug devices into other USB-ports and they are keep working anyway. :oops:

Good, then? ;-)

Pete

Posted (edited)

More news from the same field...

MS/TT panels DO WORK inside Lua, but there is a little nuance.

As we've found out their report consits of two pages (two sequential data blocks). But com.GetHidButtons doesn't differentiate them and always interprete them the same way as if it was a report about button states.

For example, when button 13 is pressed com.GetHidButtons returns this 32bit string (converted from Integer to Binary):

press : 00000000000000000001000000000000 / 13

And that is ok.

But then if device sends some data about axises` values changes, com.GetHidButtons returns new Integer genereted from the other UsagePage which does nothing with current buttons states. And now it returns another integer value, while the real buttons are still in the same state as before. And Lua script then believes that there were a real changes in button states which is not true.

The TT Panel (which doesn't have any physical axis controls) from time to time sends the all-zeroes report about axises values. And this cause com.GetHidButtons returns Zero too, which is then parsed by Lua script as a state with NO BUTTONS PRESSED.. but at the same time several buttons or switches on panel could be press or switched on. Script interpretes that Zero as a command to release all buttons, which is wrong.

On the MS Panel everything is worse, because on the second/axises page it sends not the all-zeroes report, but the real state of the real axises, which is then beeing interpreted in Lua as a "random" button presses/releases.

So.. the conclusion is: com.GetHidButtons should differentiate and don't mess two report pages with each other. But I don't know how it's could be done. I know only that on these particular devices Report 1 is about axises and Report 2 is about bouttons states.

======

I'm not sure about all that, but it looks like that very much... But still needs confirmation.

Edited by Artem Crum
Posted

So.. the conclusion is: com.GetHidButtons should differentiate and don't mess two report pages with each other. But I don't know how it's could be done.

All the Buttons and Values getting functions do is call Windows routines to decode the data already read and provided as a parameter. They will assume that the data is from the correct report, so when it isn't it will be wrong.

The answer is the same as before -- I need to work out which reports are which and use the appropriate definitions for each, or simply filter off reports not relevant. I'm sure I can do all that but I need the devices. I really HATE working in the dark, and guessing things. Sorry. It will be done, but I can't say when. I've had no reply yet from VRi.

Regards

Pete

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.