On Sun, Jul 19, 2015 at 6:06 AM, x414e54 wrote:
This seems to be getting WAY off course.
My request is for "set_cursor_position_hint" to actually move the cursor,
rather than forcing the client to make a fake cursor. It could very well
move the cursor without syncing with the drawing.
I screwed
On Wed, Jul 15, 2015 at 9:09 PM, Daniel Stone wrote:
> I haven't read the vast majority of this thread, but this isn't really
> true. There's nothing special about the cursor in drawing: just hide
> the cursor, create a small subsurface with SHM buffers, and Weston
> will use the hardware cursor a
On Wed, Jul 15, 2015 at 5:09 AM, Daniel Stone wrote:
> On 29 June 2015 at 20:22, Bill Spitzak wrote:
> > On Sun, Jun 28, 2015 at 7:32 AM, x414e54 wrote:
> >> Clients do not draw the mouse cursor, either the GPU (using hardware
> >> overlays) or the WM does.
> >
> > Yes, I want to allow clients
On 29 June 2015 at 20:22, Bill Spitzak wrote:
> On Sun, Jun 28, 2015 at 7:32 AM, x414e54 wrote:
>> Clients do not draw the mouse cursor, either the GPU (using hardware
>> overlays) or the WM does.
>
> Yes, I want to allow clients to use this CPU/WM support. Currently the
> client *has* to draw th
On Tue, Jul 14, 2015 at 4:14 PM, x414e54 wrote:
> You are either just trolling or have no idea what you are talking
> about and have never tried to implement anything you are saying.
> I stopped listening at "The render loop would be sending the
> cursor-positioning request.". Not sure how you
You are either just trolling or have no idea what you are talking
about and have never tried to implement anything you are saying.
I stopped listening at "The render loop would be sending the
cursor-positioning request.". Not sure how you cannot see the problem
with this.
I will be blocking your
On Mon, Jul 13, 2015 at 9:48 PM, x414e54 wrote:
>
> Okay lets say for whatever reason you allow the client direct access
> to set the cursor position in a way that did not introduce any extra
> lag.
>
I'm going to ignore all this, because it is obvious that what I propose has
"lag". Avoiding lag
On Tue, Jun 30, 2015 at 4:22 AM, Bill Spitzak wrote:
>
>
> On Sun, Jun 28, 2015 at 7:32 AM, x414e54 wrote:
>>
>>
>> Clients do not draw the mouse cursor, either the GPU (using hardware
>> overlays) or the WM does.
>
>
> Yes, I want to allow clients to use this CPU/WM support. Currently the
> clie
On Sun, Jun 28, 2015 at 7:32 AM, x414e54 wrote:
>
> Clients do not draw the mouse cursor, either the GPU (using hardware
> overlays) or the WM does.
>
Yes, I want to allow clients to use this CPU/WM support. Currently the
client *has* to draw the cursor (and hide the hardware one) to sync it's
p
On Tue, 23 Jun 2015 11:57:23 -0700
Bill Spitzak wrote:
> On Sun, Jun 21, 2015 at 11:46 PM, x414e54 wrote:
>
> > So in your system the compositor would have to block mouse cursor
> > movement until an application had dispatched and processed its events.
> > Literally in this instance the user w
*facepalm*
On Wed, Jun 24, 2015 at 3:57 AM, Bill Spitzak wrote:
> I am not introducing any lag. If the client takes 1/2 second to draw the
> result of a mouse movement, it will still take 1/2 second under my scheme.
> Exactly the same amount of lag. However in my scheme the cursor will be
> drawn
On Sun, Jun 21, 2015 at 11:46 PM, x414e54 wrote:
> Hi I have been away for a while and quite busy so I did not get a
> chance to response.
>
> On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak wrote:
> > No, I absolutely 100% disagree.
> >
> > Synchronized updating so things don't vibrate or shift i
On Mon, 22 Jun 2015 15:46:41 +0900
x414e54 wrote:
> This is wrong on so many levels and probably shows you either have
> never used either Weston or Gnome Shell when they had laggy slow mouse
> issues.
> I believe Gnome has partially fixed it but there was still massive lag
> when entering/exitin
Hi I have been away for a while and quite busy so I did not get a
chance to response.
On Tue, Apr 28, 2015 at 3:46 AM, Bill Spitzak wrote:
> No, I absolutely 100% disagree.
>
> Synchronized updating so things don't vibrate or shift is more important
> than FPS. It is even stated as part of Waylan
On 04/24/2015 08:51 PM, x414e54 wrote:
On Fri, Apr 24, 2015 at 6:22 PM, Pekka Paalanen wrote:
Then apps would need to know what the accel paramaters mean, which
requires us to lock down the acceleration logic and mathematical
functions in the protocol specification. I don't think that is
some
On Fri, Apr 24, 2015 at 6:22 PM, Pekka Paalanen wrote:
> Then apps would need to know what the accel paramaters mean, which
> requires us to lock down the acceleration logic and mathematical
> functions in the protocol specification. I don't think that is
> something Wayland wants to specify.
I i
On 04/24/2015 02:22 AM, Pekka Paalanen wrote:
If you have the compositor in charge of moving the cursor, and the app
in charge of scrolling and drawing the contents, you would get a lag
between the cursor moving and the content/scrollbar moving. Granted,
this is probably a minor issue and can
That is not sufficient as the application may want to put much more
complex rules on how the pointer moves (such as limiting it to a rectangle).
As a practical matter the applications that want a slow scrollbar want
*exactly* the same acceleration as before, just that the resulting
position is
On Fri, 24 Apr 2015 17:59:04 +0900
x414e54 wrote:
> If you allowed applications to control the mouse speed or acceleration
> when they have an implicit grab then when it is released it returns to
> normal. This would give GUI applications the ability to use slow
> scrollbars without having to war
If you allowed applications to control the mouse speed or acceleration
when they have an implicit grab then when it is released it returns to
normal. This would give GUI applications the ability to use slow
scrollbars without having to warp the pointer. Absolute pointing
devices could then just ign
On Thu, Apr 23, 2015 at 1:51 PM, x414e54 wrote:
> On Wed, Apr 22, 2015 at 1:52 PM, Peter Hutterer
> wrote:
>> The real problem regarding the mouse position is that you now rely on the
>> client and the compositor to calculate the cursor position exactly the same
>> way. If not, you may end up lea
On Wed, Apr 22, 2015 at 1:52 PM, Peter Hutterer
wrote:
> The real problem regarding the mouse position is that you now rely on the
> client and the compositor to calculate the cursor position exactly the same
> way. If not, you may end up leaving the window when the cursor as drawn by
> the client
On Tue, Apr 21, 2015 at 06:05:02PM -0700, Bill Spitzak wrote:
> Interesting. It does seem like a good idea to do remote by providing
> identical device api's. This probably applies to sound output too. There
> will have to be simple and obvious methods to figure out the remote machine
> so that all
On Wed, Apr 22, 2015 at 10:05 AM, Bill Spitzak wrote:
> If a client opens a device, will that interfere with wayland's reading of
> the device? For instance if the client opens the mouse, will wayland still
> get the mouse position such that it can revoke access when the cursor moves
> out of the
Interesting. It does seem like a good idea to do remote by providing
identical device api's. This probably applies to sound output too. There
will have to be simple and obvious methods to figure out the remote
machine so that all other devices besides the display go to the same
one, and there w
On Sun, Apr 19, 2015 at 12:45:09PM +0100, Steven Newbury wrote:
> On Sun, 2015-04-19 at 15:29 +0900, x414e54 wrote:
> >
> >
> > The way todo this seems to be for the compositor and client to
> > negotiate an event type they both can understand such as
> > libinput_event or hid events and then a
2015/04/21 5:42 "Bill Spitzak" :
>
> On 04/18/2015 03:20 AM, Hans de Goede wrote:
>
>> 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 whi
On 04/18/2015 03:20 AM, Hans de Goede wrote:
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 20 April 2015 at 14:49, x414e54 wrote:
>>> There is no sense in saying the sensor reading itself as absolute or
>>> relative. Either gives you some number in unknown units which you
>>> calibrate to get usable results. You have no idea where the stick is
>>> from the numbers you get. And there
On 20 April 2015 at 13:44, x414e54 wrote:
> This is kinda completely derailed from the whole include mice in the
> game controller protocol talk.
>
> On Mon, Apr 20, 2015 at 6:44 PM, Michal Suchanek wrote:
>> On 20 April 2015 at 10:48, Pekka Paalanen wrote:
>>> On Mon, 20 Apr 2015 10:13:34 +0200
>> There is no sense in saying the sensor reading itself as absolute or
>> relative. Either gives you some number in unknown units which you
>> calibrate to get usable results. You have no idea where the stick is
>> from the numbers you get. And there is absolutely no point caring. It
>> may have s
This is kinda completely derailed from the whole include mice in the
game controller protocol talk.
On Mon, Apr 20, 2015 at 6:44 PM, Michal Suchanek wrote:
> On 20 April 2015 at 10:48, Pekka Paalanen wrote:
>> On Mon, 20 Apr 2015 10:13:34 +0200
>> Michal Suchanek wrote:
>>
>>> On 20 April 2015
On 20 April 2015 at 10:48, Pekka Paalanen wrote:
> On Mon, 20 Apr 2015 10:13:34 +0200
> Michal Suchanek wrote:
>
>> On 20 April 2015 at 09:36, Pekka Paalanen wrote:
>> > On Sun, 19 Apr 2015 09:46:39 +0200
>> > Michal Suchanek wrote:
>> >
>> >> So the device is always absolute and interpretation
On Mon, 20 Apr 2015 10:13:34 +0200
Michal Suchanek wrote:
> On 20 April 2015 at 09:36, Pekka Paalanen wrote:
> > On Sun, 19 Apr 2015 09:46:39 +0200
> > Michal Suchanek wrote:
> >
> >> So the device is always absolute and interpretation varies.
> >
> > I disagree.
> >
> > Let's take a mouse, opt
On Mon, Apr 20, 2015 at 4:36 PM, Pekka Paalanen wrote:
>> >> On 18 April 2015 at 16:58, x414e54 wrote:
>>
>> >>> USB HID specifications define a pointer and a mouse as two completely
>> >>> different inputs. A mouse can be a used as a pointer because it is
>> >>> pushing the cursor around but the
On 20 April 2015 at 09:36, Pekka Paalanen wrote:
>> >> On 18 April 2015 at 16:58, x414e54 wrote:
>>
>> >>> USB HID specifications define a pointer and a mouse as two completely
>> >>> different inputs. A mouse can be a used as a pointer because it is
>> >>> pushing the cursor around but the point
> >> On 18 April 2015 at 16:58, x414e54 wrote:
>
> >>> USB HID specifications define a pointer and a mouse as two completely
> >>> different inputs. A mouse can be a used as a pointer because it is
> >>> pushing the cursor around but the pointer points at a specific
> >>> location.
Okay. Using d
On Sun, 2015-04-19 at 15:29 +0900, x414e54 wrote:
>
>
> The way todo this seems to be for the compositor and client to
> negotiate an event type they both can understand such as
> libinput_event or hid events and then a way to request a revokable
> fd to the evdev directly so it can control LED
On 19 April 2015 at 06:15, x414e54 wrote:
> On Sun, Apr 19, 2015 at 12:45 AM, Michal Suchanek wrote:
>> On 18 April 2015 at 16:58, x414e54 wrote:
>>
>>>
>>> A joystick does not necessarily have 2 axis and in most cases yes they
>>> are reporting an absolute position of the axis in the driver bu
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
> 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 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
> 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 solutions, except you have moved
On 04/16/2015 07:51 PM, x414e54 wrote:
Hi,
I am wondering if there has been any recent progress on the stability of
the Wayland relative pointer API?
I had a few ideas on the original December implementation:
Whilst we definitely need the relative event support, I feel that the
client should
On Fri, 17 Apr 2015 19:14:30 +0900
x414e54 wrote:
> If the compositor can handle this by creating its own evdev device fd
> then having the client use libinput to receive the raw relative mouse
> motion events and dpi information then this seems a very acceptable
> solution. I am not sure though
On 17 April 2015 at 14:37, Hans de Goede wrote:
> Hi,
>
>
> On 17-04-15 13:17, Michal Suchanek wrote:
>>
>> 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:
>
Hi,
On 17-04-15 13:17, Michal Suchanek wrote:
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 c
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 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 will leave after that.
Not sure an IR/laser/wii mote pointer should even be con
Yes thank you for the comments.
I have added a bug/enhancement report related to dealing with this
from the evdev fd or libinput side. I do not have a huge amount of
time so please feel free to re-word it if you think of a better way.
If the compositor can handle this by creating its own evdev d
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 will leave after that.
>>
>> >
>> > Not sure an IR/laser/wii mote pointer should even be considered a
>> > "relative" poin
On Fri, 17 Apr 2015 13:43:11 +0900
x414e54 wrote:
> Thank you for the comments.
> I do have a few counterpoints but I will leave after that.
>
> >
> > Not sure an IR/laser/wii mote pointer should even be considered a
> > "relative" pointer since they operate in absolute coordinates. Given
> > th
If you add in something like get a wl_input from a wl_seat which can
be used as a generic interface to access the libinput directly in a
safe way but still controlled the compositor if the window loses focus
or there needs to be some translation done. This would be much more
generic than my wl_jost
Actually sorry I was wrong. UE4 uses HID raw input but there are some
older game engines that used to use directinput.
On Fri, Apr 17, 2015 at 1:43 PM, x414e54 wrote:
> Thank you for the comments.
> I do have a few counterpoints but I will leave after that.
>
>>
>> Not sure an IR/laser/wii mote p
Thank you for the comments.
I do have a few counterpoints but I will leave after that.
>
> Not sure an IR/laser/wii mote pointer should even be considered a
> "relative" pointer since they operate in absolute coordinates. Given
> this, there is no "set position" hint to consider. Transmitting
> ac
On Fri, Apr 17, 2015 at 11:51:41AM +0900, x414e54 wrote:
> Hi,
>
> I am wondering if there has been any recent progress on the stability of
> the Wayland relative pointer API?
AFAIK it is being / to be reviewed a bit more. I have some kind of plan
to submit a version with the previous issues addr
Hi,
I am wondering if there has been any recent progress on the stability of
the Wayland relative pointer API?
I had a few ideas on the original December implementation:
Whilst we definitely need the relative event support, I feel that the
client should never be allowed to warp or confine the gl
63 matches
Mail list logo
