From the top just, to get our way through this treacle, what a game wants is:
1. Enumerate input devices.
2. Select the HID type each player wants and get a device that
supports that usage.
e.g. Mouse type devices - (could be thumb-stick, pointer stick, mouse,
accelerometer, trackpad or pen as lo
On Sun, Apr 19, 2015 at 12:45 AM, Michal Suchanek wrote:
> On 18 April 2015 at 16:58, x414e54 wrote:
>>> Hi,
>>>
>>> then actually mice are absolute not relative. They have two axis that
>>> measure absolute ball rotation speed in two directions just like
>>> joystick has two axis that measure ab
This is why my original suggestion was for a generic controller
protocol similar to DirectInput or pass libinput events directly
similar to HID RawInput rather than a fd.
Also even if you are passing a fd it does not mean it needs to
re-implement trackpad support, if they driver exports a mouse HI
Hi,
On 18-04-15 16:03, x414e54 wrote:
Right.
This has been discussed before, and as mentioned before I really
believe that we should not define a joystick API at all,
rather we should define an API which will allow an app to:
1) List devices which it can get raw access to
2) Request raw access
On 18 April 2015 at 16:58, x414e54 wrote:
>> Hi,
>>
>> then actually mice are absolute not relative. They have two axis that
>> measure absolute ball rotation speed in two directions just like
>> joystick has two axis that measure absolute stick excentricity.
>>
>> Thanks
>>
>> Michal
>
> This is
> Hi,
>
> then actually mice are absolute not relative. They have two axis that
> measure absolute ball rotation speed in two directions just like
> joystick has two axis that measure absolute stick excentricity.
>
> Thanks
>
> Michal
This is not really constructive to the api but:
Mice are not a
Hey Jonas,
On vie, 2015-04-17 at 15:50 +0800, Jonas Ådahl wrote:
>
> > For the touch case, depending on how the grab is implemented, with
> > the
> > current guidelines the only 2 choices are "leave the client in
> > inconsistent state" or "make the client still receives ongoing
> > touches
>
> Right.
>
> This has been discussed before, and as mentioned before I really
> believe that we should not define a joystick API at all,
> rather we should define an API which will allow an app to:
>
> 1) List devices which it can get raw access to
> 2) Request raw access, if this succeeds the app
On 17 April 2015 at 23:40, Bill Spitzak wrote:
> On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
>
>> Let's expand on that example, maybe far-streched, but certainly possible:
>> - I'm manipulating a client window with 2 fingers on the touchscreen
>> (say zooming an image)
>> - Any other interactio
On 17 April 2015 at 12:52, Hans de Goede wrote:
> Hi,
>
>
> On 17-04-15 11:47, Michal Suchanek wrote:
>>
>> On 17 April 2015 at 09:11, Pekka Paalanen wrote:
>>>
>>> On Fri, 17 Apr 2015 13:43:11 +0900
>>> x414e54 wrote:
>>>
Thank you for the comments.
I do have a few counterpoints but I
Hi,
On 18-04-15 03:35, x414e54 wrote:
A big problem with just saying "the game must use the joystick api" is that
the game won't work on a machine without a joystick unless the joystick api
is emulated for the mouse. This seems to me to be exactly the same problem
and requiring exactly the same
11 matches
Mail list logo
