<div dir="ltr"><div>Todd,<br></div>I think you forgot reply-all. I add wayland-devel again.<br><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 26, 2013 at 5:50 PM, Todd Showalter <span dir="ltr"><<a href="mailto:todd@electronjump.com" target="_blank">todd@electronjump.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, Apr 26, 2013 at 5:46 PM, Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote:<br>
<br>
> My first general comment is about floating point. I'm not 100% sure what<br>
> all went into the design decision to make wl_fixed have 8 bits of fractional<br>
> precision vs. 12 or 16. I'm guessing that they wanted the increased integer<br>
> capability, but you'd have to ask Kristian about that. My understanding is<br>
> that most game controllers work with ranges of [0,1] or [-1,1] which would<br>
> be wasteful to put into wl_fixed. Looking below, it seems as if you're<br>
> fairly consistently picking a 16 bit fractional part. That breaks out of<br>
> the norm of the wire format a bit, but I think it's justified in this case.<br>
> The big thing is to be consistent which it looks like you're doing anyway.<br>
<br>
</div> In my experience, most game controllers actually return byte<br>
values which you wind up interpreting either as signed or unsigned<br>
depending on what makes sense. Certainly that's been the case<br>
historically. In games we typically do something like:<br>
<br>
stick.x = ((float)raw_x) / (raw_x >= 0) ? 127.0f : 128.0f;<br>
stick.y = ((float)raw_y) / (raw_y >= 0) ? 127.0f : 128.0f;<br>
<div class="im"><br>
> Another concern is how to map [0, 255] onto [0, 2^15 - 1] cleanly.<br>
> Unfortunately, there is no good way to do this so that 0 -> 0 and 255 -><br>
> 2^15 - 1. Perhaps that doesn't matter much for games since you're sensing<br>
> human movements which will be slightly different for each controller anyway.<br>
<br>
</div> There is, actually:<br>
<br>
expanded = (base << 7) | (base >> 1);<br>
<br>
ie: repeat the bit pattern down into the lower bits. Examples:<br>
<br>
11111111 -> (111111110000000) | (1111111) -> 111111111111111<br>
0000000 -> (0000000000000000) | (0000000) -> 000000000000000<br>
1000000 -> (1000000000000000) | (100000) -> 100000001000000<br>
1011001 -> (10110010000000) | (101100) -> 1011001101100<br>
<br>
And so forth. It's the same scheme you use when doing color<br>
channel expansion. I haven't seen a rigorous mathematical proof that<br>
it's correct, but I'd be surprised if someone more so inclined than I<br>
hasn't come up with one.<br></blockquote><div><br></div><div>Wow, I've never seen that one before. And yes, it is provably exactly correct (up to a little integer round-off because of the implicit right shift by 1). I guess I learned a new trick today; that's really cool!<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[wl_gamepad::connect and disconnect]<br>
<div class="im"><br>
> Do we really need connect and disconnect timestampped? Are those timestamps<br>
> going to be reliable/useful? When you plug in a device, it takes a second<br>
> or two just to detect and show up in /dev. On that time scale, "when did I<br>
> see the event?" is just as accurate as any timestamp.<br>
<br>
</div> It seemed like all events had timestamps as part of the protocol,<br>
so I didn't know how fundamental that was to the underlying system.<br>
The only reason connect and disconnect might need to be timestamped is<br>
if events are going to be batched up, you might possibly have ordering<br>
issues with delivery. If that's not a problem and the underlying<br>
system doesn't require timestamps, they can go.<br>
<br>
[wl_gamepad::button]<br>
<div class="im"><br>
>> The trigger_index is 0 for left stick values and 1 for right stick<br>
>> values. Hardware with more triggers can potentially supply higher<br>
>> values; the pressure-sensitive buttons on the ps3 controller would go<br>
>> here, for instance.<br>
><br>
> Could you be more clear about what other pressure-sensitive buttons on the<br>
> PS3 controller you're referring to here? I know they went a bit overboard<br>
> on pressure sensitivity in the PS3 controller and seem to recall that even<br>
> buttons like triangle etc. were pressure-sensitive. That said, those<br>
> buttons should map as buttons not triggers so that they can be picked up in<br>
> a canonical way. Are you simply planning to double-report events there?<br>
<br>
</div> I included this as a "this data could work without breaking the<br>
protocol", but it's not essential.<br>
<br>
In the particular case of the ps3 (and all of the dual shock<br>
controllers, IIRC), all of the buttons are pressure sensitive with a<br>
[0..255] range except "start", "select", "home" (on pads that have it)<br>
and the stick clicks. The face buttons, the dpad and all four<br>
shoulder buttons are pressure sensitive. Whether it's worth exporting<br>
that is another question entirely; I've heard rumour that the ps4<br>
controller removes pressure sensing from a lot of the buttons.<br>
<br>
[wl_gamepad::extended]<br>
<div class="im"><br>
> My feeling on this would be to wait until we have a use-case for it. We can<br>
> always bump the version and add an event if it comes up. I think that's<br>
> better than just assuming we can do something sensible with four generic<br>
> parameters.<br>
<br>
</div> This is partly in response to things like the razer Wiimote-like<br>
contraption that apparently spits out piles of quaternions, and also<br>
things like hardcore flightsticks that have things like fixed-range<br>
throttles. I'm not convinced it's needed either, but I figured if I<br>
was making a proposed protocol it was worth throwing it in for the<br>
sake of discussion.<br>
<div class="HOEnZb"><div class="h5"><br>
Todd.<br>
<br>
--<br>
Todd Showalter, President,<br>
Electron Jump Games, Inc.<br>
</div></div></blockquote></div><br></div></div>