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 11:55 AM, Peter Hutterer
wrote:
> On Wed, Jul 15, 2015 at 08:23:09AM +0900, x414e54 wrote:
>> Hi,
>>
>> Just a quick questions:
>>
>> 1) Is there any way to un-normalize the values?
>
> not at this point, no.
> fwiw as of libinput
Hi,
Just a quick questions:
1) Is there any way to un-normalize the values?
2) What happens with >1000hz gaming mice for example which need
microsecond granularity timestamps?
On Mon, Jun 29, 2015 at 3:54 PM, Peter Hutterer
wrote:
> On Fri, Jun 26, 2015 at 12:38:01PM +0800, Jonas Ådahl 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 cannot see the problem
with this.
I will be blocking your
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
*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
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 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
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
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 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
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
>> 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 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 be
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
growth of game
innovation on Linux by whatever a small group of people decide a
"wl_pointer" is.
On Sun, Apr 19, 2015 at 6:55 AM, Hans de Goede wrote:
> Hi,
>
>
> On 18-04-15 16:03, x414e54 wrote:
>>>
>>> Right.
>>>
>>> This has been disc
> 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
> 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
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
wl_jostick or wl_6dof proposal.
On Fri, Apr 17, 2015 at 1:48 PM, x414e54 wrote:
> 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 commen
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
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
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
I have been working on a GUI toolkit and looking to experiment porting it
to wayland.
Currently I am using a wl_shell_surface and have dialogs, tooltips, etc.
working fine, just waiting on relative mouse for implementing spinners,
rotations etc.
However I am looking at positioning the initial par
Ekstrand
wrote:
> On Sat, Mar 28, 2015 at 6:57 AM, x414e54 wrote:
>
> > I was originally blitting the texture to the default framebuffer and then
> > trying to use eglSwapBuffers. But for some reason eglSwapBuffers was
> > returning EGL_BAD_SURFACE even though eglMakeCurrent ha
29 matches
Mail list logo
