Skip to content

Add MSC timestamp event - #40

Open
medakk wants to merge 3 commits into
ardaku:stablefrom
medakk:add_linux_msc
Open

Add MSC timestamp event#40
medakk wants to merge 3 commits into
ardaku:stablefrom
medakk:add_linux_msc

Conversation

@medakk

@medakk medakk commented Nov 25, 2021

Copy link
Copy Markdown

Adds handling for timestamp events on linux. These events are sent by Nintendo joycons(I'm not aware of any other controller that sends this information) As I understand this can be used to correlate timing with gyro/accelerometer readings sent. (See here )

Here's the relevant part of the event code documentation

EV_MSC:
----------
EV_MSC events are used for input and output events that do not fall under other
categories.

A few EV_MSC codes have special meaning:

* MSC_TIMESTAMP:
  - Used to report the number of microseconds since the last reset. This event
    should be coded as an uint32 value, which is allowed to wrap around with
    no special consequence. It is assumed that the time difference between two
    consecutive events is reliable on a reasonable time scale (hours).
    A reset to zero can happen, in which case the time since the last event is
    unknown.  If the device does not provide this information, the driver must
    not provide it to user space.

Also: I'm not sure whats the from_id and to_id stuff and just added the next number in the series.

@medakk

medakk commented Nov 25, 2021

Copy link
Copy Markdown
Author

I've tested the changes on raspbian 10

@AldaronLau

Copy link
Copy Markdown
Member

@medakk Thanks, this looks great! One small nitpick before I merge it: Instead of returning the microsecond value directly from the Linux kernel, I would like it to be an instance of std::time::Duration constructed with std::time::Duration::from_micros().

The reason for this is that I'd like to use a type that's name describes what it is (I believe this is important for measurement units, such as time). The precision of microseconds is somewhat arbitrary, and in the future it might be possible some other device supports nanoseconds (although the usefulness of that might be questionable). Although this does increase the size of Event, it should be acceptable since typically after events are created, they are matched on immediately.

I'm also thinking maybe the event should be called Uptime rather than Timestamp, since usually timestamps are associated with other events.

BTW I'm hoping I can fix #38 today, which should make it possible to start looking into #39 again.

@AldaronLau

Copy link
Copy Markdown
Member

@medakk Actually, scratch that. I'm planning on merging code that changes a lot of the organization of code in the repository today, so I'll just merge this when I do and make the necessary changes to avoid a mess of merging.

@medakk

medakk commented Nov 29, 2021

Copy link
Copy Markdown
Author

Thanks @AldaronLau ! yes std::time::Duration makes more sense here!

Regarding #39 , with this PR (#40) and the WIP PR #38, I am able to use my joycons' accelerometer. I'm just not sure what the scale is, but admittedly I haven't dug into it too much since its fine for my current project

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants