Missing com.readfeature

[wstrzalka]

Hi

  I do really miss Lua functionality to read HID feature report. Smth with signature com.readfeature(handle, reportID). 

It would be complementary to existing com.writefeature(...) 

Regards

 Wojtek

 

 

[Pete Dowson]

53 minutes ago, wstrzalka said:

  I do really miss Lua functionality to read HID feature report. Smth with signature com.readfeature(handle, reportID). 

It would be complementary to existing com.writefeature(...) 

Actually, I don't recall ever hearing from anyone having used even the latter. I've never had any way of testing it, apparently not having any devices with 'features'.  What device are you using where these functions are useful?

I see that there is indeed a "GetFeature" function in the HID API which I could use.  (The writefeature function uses the API's "SetFeature").

Can I ask which version of FSUIPC you are using? I would be amenable to implementing a "readFeature" function for Lua in FSUIPC5, which is subject to full development still, but I'd be more reluctant with FSUIPC4, or is it WideClient you are interested in?

Either way I'd have to ask you to test it. (Well both Read and Write, really).

Pete

 

[wstrzalka]

I'm on version 4 atm - still with FSX ;)

Currently I'm focused on hardware work but once complete I'm planning to jump to new P3D and FSUIPC - maybe also WideClient - but I'm not using it at the moment. 

Regarding use case I'm working on my custom hardware and using HID features for device configuration (so the device remembers whether it's COM1 or COM2, display brightness etc..) 

[Pete Dowson]

27 minutes ago, wstrzalka said:

Regarding use case I'm working on my custom hardware

Ah, you design your own? Very clever. Do you use stock USB/HID chips?

I'll put "readfeature" on my list of "things to do", but at present can't promise any timescale. It might not be till mid-October or later.

Pete

 

[wstrzalka]

Thanks.

 

I do use Atmega chip with builtin hardware USB support. A bit of C++ does the rest :)

At the moment I'm finishing KX155 COM/NAV radio (both device C++ program & LUA FSUIPC plugin to talk to sim are ready (almost) - still need some smart way to get nice panel).

The device are 1:1 size & layout with original Bendix/King. I do have PCB manufactured for KT76 transponder & KR87 ADF so I'm going to start assembling them this week. And more to come ... 

Wojtek

 

[wstrzalka]

One more thing I wanted to achieve with readfeature is to check if the device is still there, as I think there is currently no way to detect it from the script for non-joystick device (write always returns the amount of bytes to be written for me). Or maybe I'm wrong and there is a way?

Wojtek

[Pete Dowson]

12 hours ago, wstrzalka said:

One more thing I wanted to achieve with readfeature is to check if the device is still there, as I think there is currently no way to detect it from the script for non-joystick device

Sorry, I don't know. I do get notifications of USB devices connecting or disconnecting. I normally take no notice except for Joysticks which are assigned, which provokes a re-scan.

I suppose I could add a facility for an event to be triggered on an opened device disconnect/reconnect, if I can tie the details in the connection change notice with the device you have opened. Assuming I can it would be something like 

event.comconnect(dev, "function name")

with thefunction being provided with a boolean indicating connection or disconnection.

But I'm not sure about that. I'm wondering if the handle ("dev" here) effectively becomes invalid if the device disconnects, in any case. I'd have to investigate all this before I did anything.

Of course readfeature used for this would only be of any use if you knew that the device does suppert this and always has feature data to supply.

Pete

 

 

[wstrzalka]

That's exactly the difference between regular reports & feature reports. The later once are always there so you can always request a read. 

That's of course workaround and it would be much more convenient to have API for that. If com.openhid handle is OS handle I'm pretty sure it becomes invalid forever after you disconnect so the API would be more like one shot event.afterDisconnect.

If they are your internal handles sky is the limit...  :) 

Currently I did found some magic offset that gets set any time smth major happens (don't remember exact value right now but it's set also when any HID connects) and I reconnect just in case every time it's set. Works but if there would be more gentle way of doing that it would be great. 

 

Anyway big respect as I was able fully program 2 way communication using FSUIPC plugin infrastructure. I initially started with custom C# app but it got too heavy and I abandoned it on behalf of Lua.

 Feature read and disconnect notification are just a cherries on a pie to make things more compact and smooth :) 

[Pete Dowson]

I did take a look at what is involved in adding a com.readfeature function, and in fact it would be a lot less hassle for me if I went that way.

In view of what you say about handles, I could, rather than trying to relate the disconnect and newly connected notifications to the handles which are/were opened (which is rather messy), I think I'd rather do something like saving the last error return I got (read by something like GetLastError in C) whist issuing commands for the device, and providing them on a request such as

n = com.geterror(dev)

The handles in the 32-bit FSUIPC4 are the 'real' ones. In FSUIPC5, the handles are references to an internal table of handles internally, because for the 64-bit Windows API the handles (theoretically) occupy 64-bit integers, and the current Lua interpreter I'm using still uses 32-bits.

Pete

 

[wstrzalka]

10 hours ago, Pete Dowson said:

I think I'd rather do something like saving the last error return I got (read by something like GetLastError in C) whist issuing commands for the device, and providing them on a request such as

n = com.geterror(dev)

 

That would be beneficial on it's own but not fully functional complete for the use case of device disconnect.

If you have input only device (eg. standard joystick) or like my radios input with output loopback (in perfect situation information on display changes only after I create an input from device first: knob turn results in displayed frequency change), and you want to use event library for read you will never find out smth got broken - as there will no longer be input from device there will be no output and no output is no error.

I did some research and I think best would be to register in OS using this API: RegisterDeviceNotification  on com.hidopen(), with complementary UnregisterDeviceNotification on com.close()

Having that app will receive WM_DEVICECHANGE with two most interesting notification DBT_DEVICEREMOVECOMPLETE and DBT_DEVICEARRIVAL

Looking at the DBT_DEVICEARRIVAL I'm no longer 100% sure wheather the handle gets invalid after disconnect (it definitelly does in FSUIPC). That would need to be tested in detail ... 

[Pete Dowson]

2 hours ago, wstrzalka said:

I did some research and I think best would be to register in OS using this API: RegisterDeviceNotification  on com.hidopen(), with complementary UnregisterDeviceNotification on com.close()

I already register for notifications, that's how FSUIPC decides to do a joystick rescan when a device connects -- in case it is a joystick type and the user then wants to make assignments to it.

I don't think those API's are device specific. I can't see how to use them in the way you seem to wish. Maybe I'm missing something?

Pete

 

[wstrzalka]

So if a rescan functionality is already built-in (and potentially can be extended to non-joystick devices) it should be quite simple to validate if the devices being opened with com.openhid() are still in system - especially for FSUIPC 5 where you do have mapping table already implemented. It would probably need to keep track of VID/PID/NO (or entire device path), not only map number to number but it seems doable [ I'm aware things seems much easier when you don't have too work on them, then when you have to code it :) ]

BTW - I had just found that the offset I'm using to force a device reconnect works only when LINDA software is turned on, so it's probably theirs custom hack to notify Lua to do device checks.

 

 

[Pete Dowson]

1 hour ago, wstrzalka said:

So if a rescan functionality is already built-in (and potentially can be extended to non-joystick devices) it should be quite simple to validate if the devices being opened with com.openhid() are still in system - especially for FSUIPC 5 where you do have mapping table already implemented. It would probably need to keep track of VID/PID/NO (or entire device path), not only map number to number but it seems doable [ I'm aware things seems much easier when you don't have too work on them, then when you have to code it :) ]

As I said a few messages back, it is possible, yes, but it is messy. Something maybe to look at one day, but the demand is very small (i.e. only you). Sorry to be so blunt. Easy things I add easily, messy things need a lot more thought before potentially making things worse instead of better.

Most folks using HID devices either don't remove them during a session, or if they do, understand they will need to restart anything using them. Even FS doesn't cope with losing a joystick midsession -- you have to restart it. At least FSUIPC does cope -- that was one of the earlier improvements over FS behavious I added.

It will be much easier to add the readfeature function, which I will do. But it will be in FSUIPC5 first because that is under more active development.

Pete

 

[Pete Dowson]

Okay. Big omission from the Lua com lbrary documentation.

I was looking into adding "com.readfeature", so I looked at the code. It is already implemented! It was included at the same time as all the other HID functions. I don't know how it missed out in the documentation.

There's also "com.readreport" omitted! 

I think they were omitted because I had no way of testing them, no way of determiniing whether the results were correct even if I had appropriate devices. 

I've now found that the GoFlight T8, P8 and RP48 devices have feature bytes, as do the Leo Bodnar BU0836 boards, so I could actually test that they do something. But whether what you get is right is another matter.

If you'd be so good as to test them on devices you know and let me know. If okay I'll add them to the documentation. Meanwhile here is what the entries would read:

str, n = com.readfeature(handle, repno)	Reads the feature bytes from the HID device via the “GetFeature” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.
str, n = com.readreport(handle, repno)	Reads the input report bytes from the HID device via the “ReadInputReport” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.

[Pete Dowson]

One other good news item.

Whilst browsing my code (and this area of it dates back to forgotten times for me. That's the trouble with old age!), I see two things:

1. I keep a register not only of all the devices open and their handles (real and Lua), but also their full path names. And

2. The notifications for devices connecting and disconnecting does provide their full path names.

So, for any device, it looks a fairly easy matter for me to add either events for device connection and disconnection (though the former may not be useful if the device handle isn't valid in any case for a disconnected device -- but that's something I can check later), or a "com.testconnected" function, or possibly both ways. I can certainly either make the Lua handle invalid when the device isn't connected, or at least set a flag so that a suitable error return can be made when an attempt is made to use it. All this needs a little more research.

Thus, not "messy" at all, really, but probably quite tidy! Sorry about my earlier pessimism.

I probably won't be doing any of that in WideClient though. And I can't say when I can get to it in FSUIPC at present.

BTW, I'm away from this afternoon until Monday morning.

Pete

 

 

[wstrzalka]

On 28.09.2017 at 12:34 PM, Pete Dowson said:

Okay. Big omission from the Lua com lbrary documentation.

I was looking into adding "com.readfeature", so I looked at the code. It is already implemented! It was included at the same time as all the other HID functions. I don't know how it missed out in the documentation.

There's also "com.readreport" omitted! 

I think they were omitted because I had no way of testing them, no way of determiniing whether the results were correct even if I had appropriate devices. 

I've now found that the GoFlight T8, P8 and RP48 devices have feature bytes, as do the Leo Bodnar BU0836 boards, so I could actually test that they do something. But whether what you get is right is another matter.

If you'd be so good as to test them on devices you know and let me know. If okay I'll add them to the documentation. Meanwhile here is what the entries would read:

str, n = com.readfeature(handle, repno)	Reads the feature bytes from the HID device via the “GetFeature” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.
str, n = com.readreport(handle, repno)	Reads the input report bytes from the HID device via the “ReadInputReport” call. The report ID to be used is given as “repno”, or 0 if none are used. The returned value gives the data returned by the device, with the report ID in the first byte. “n” is zero if there was an error.

That's great news. I will test (hopefully over the weekend) and get back to you. 

[wstrzalka]

On 28.09.2017 at 1:19 PM, Pete Dowson said:

Thus, not "messy" at all, really, but probably quite tidy! Sorry about my earlier pessimism.

I had read both messages same time so I was sad entire 20 seconds ;) 

[wstrzalka]

9 hours ago, wstrzalka said:

That's great news. I will test (hopefully over the weekend) and get back to you. 

I can confirm com.readfeature & com.writefeature work like a charm :D

[Pete Dowson]

2 hours ago, wstrzalka said:

I can confirm com.readfeature & com.writefeature work like a charm :D

Good. Thank you for letting me know!

Pete

 

[Pete Dowson]

FSUIPC 4.971b and 5.121c are now released -- see Download Links. The Lua facilities to check HID device connection status have been added.

 

[wstrzalka]

5 hours ago, Pete Dowson said:

FSUIPC 4.971b and 5.121c are now released -- see Download Links. The Lua facilities to check HID device connection status have been added.

 

Smth doesn't work for me:

********* LUA: "KX155" Log [from FSUIPC version 4.971b] *********
    80684 System time = 15/10/2017 19:10:22, Simulator time = 19:09:05 (18:09Z)
    80684 LUA: beginning "E:\FSX\Modules\driver\KX155.lua"
    80700 LUA: LINDA:: [LIB]  FSX Functions loaded...
    80700 LUA: [KX155] *********************** STARTING KX155 DRIVER ***********************
    80700 LUA: [KX155] RELOAD !!!!!!!!!!!!!!!!
    80700 LUA: [KX155] Checking connection ...
    80700 LUA: [KX155] Connecting ...
    80700 LUA: [KX155] Connecting to VID:03EB PID:2062
    80715 LUA: [KX155] HID device found
    80731 LUA: [KX155] HID report received
    80731 LUA: [KX155] Handling HID report (3 bytes):  01 00 04
    80731 LUA: [HID] Button 10 ON. Executing function: ComNav2_Power_on()
    80747 *** LUA Error: E:\FSX\Modules\driver\KX155.lua:188: attempt to call field 'devconnect' (a nil value)

While KX155.lua:187-189 looks like this:

event.com(handle, 3, 3, "onHidReport")
event.devconnect(handle, "onDeviceStatusChange")
event.offset(0x3118, "UW", "onCom2ActiveFrequencyChange")

Seems like the new DLL was loaded but the function is not there .... 

[Pete Dowson]

event.comconnect, not event.devconnect.

Did I document it wrongly? Let me check ... oops! Yes I did. Sorry!  Too hasty with documentation. Never did like doing it. Not fun like programming!

Will fix that immediately!

Pete

 

 

[wstrzalka]

With the function name correction it works as expected.

Thanks a lot !!!! 

[wstrzalka]

There is one minor issue I think

When I do play with it and connect/disconnect device, I do full device reinitialization (including com.close() and then com.openhid()).

Everything works OK but I noticed in the log file that with every such a cycle I do get one more events on every disconnected & re-connected.

Seems like com.close() is leaving some data.

It's not really an functional issue as with com.connected() only first from the series has status 2/3 while the shadows have 0/1 and those are easily ignorable () but I think it's worth you're aware in case there is smth bigger behind it ...

Sample log:

   237246 LUA: Waiting for an event in "E:\FSX\Modules\driver\KX155.lua"
   254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua"
   254999 LUA: Device disconnected
   254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua"
   254999 LUA: Device disconnected noop
   254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua"
   254999 LUA: Device disconnected noop
   254999 LUA: HID Connection event: calling "onDeviceStatusChange" in "E:\FSX\Modules\driver\KX155.lua"
   254999 LUA: Device disconnected noop
   254999 LUA: Waiting for an event in "E:\FSX\Modules\driver\KX155.lua"

Regards 

     Wojtek

 

[Pete Dowson]

1 hour ago, wstrzalka said:

When I do play with it and connect/disconnect device, I do full device reinitialization (including com.close() and then com.openhid()).

Everything works OK but I noticed in the log file that with every such a cycle I do get one more events on every disconnected & re-connected.

Seems like com.close() is leaving some data.

Sorry, I'm don't understand.

Whatis this log from? What does it mean?

1 hour ago, wstrzalka said:

254999 LUA: Device disconnected noop

and here:

1 hour ago, wstrzalka said:

only first from the series has status 2/3 while the shadows have 0/1

That makes no sense if you are only using the event, as it only supplies TRUE or FALSE, there are no 0, 1 ,2 ,,3 values!

Please explain what YOU think that log is showing.

Pete