On Mon, 06 May 2013 11:07:03 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > sending pointer axis events (i.e. scroll wheel) to the window with
> > the keyboard focus is... unexplored. If it is ok to send axis events
> > outside of a wl_pointer.enter/leave pair, then it's perfectly doabl
On Mon, 06 May 2013 18:01:11 +0200
Markus Germann wrote:
> Just of curiosity, are the axis events of a joystick handled the same
> way as a scroll wheel? Because they (joysticks as input devices) might
> then be affected as well. I just mention that in order for you to keep
> in mind, that the
Todd Showalter wrote:
On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk wrote:
A compositor could just drop events that aren't over a focused window,
and it would solve Todd's problem, unless he's also expecting to be
able to scroll things without hovering over them.
My problem is that I
Vincent Povirk wrote:
Windows used to do this and it is completely nuts. They fixed it in recent
versions
Some toolkits on Windows, like gtk, direct scroll wheel input based on
cursor position, but they're not really using the native windowing
system for their widgets. The upshot of this is
On Mon, May 6, 2013 at 9:06 PM, Vincent Povirk wrote:
> A compositor could just drop events that aren't over a focused window,
> and it would solve Todd's problem, unless he's also expecting to be
> able to scroll things without hovering over them.
My problem is that I expect one of two case
> Windows used to do this and it is completely nuts. They fixed it in recent
> versions
I don't know what version of Windows you're using, but I can still
observe this behavior in the Windows 8 file dialogs. I wrote a program
to work around it: https://github.com/madewokherd/xscrollwheel
Some to
Jason Ekstrand writes:
>> Scenario 2) Two users are using a multi-user display server. Each user
>> has a keyboard, mouse, and gamepad. User 2 has to set up their wl_seat
>> using some
>> configuration window built into the display server, but once that's done
>> each user can jump in and out of a
On Mon, May 6, 2013 at 5:10 PM, Rick Yorgason wrote:
> Pekka Paalanen writes:
> > This design allows several gamepads associated with one wl_seat, and
> > thus one focus. It also allows gamepads to be assigned to different
> > seats, but then we will have more problems on managing the foci, not
Pekka Paalanen writes:
> This design allows several gamepads associated with one wl_seat, and
> thus one focus. It also allows gamepads to be assigned to different
> seats, but then we will have more problems on managing the foci, not
> unlike with keyboards. Hopefully there are no protocol design
On Mon, May 6, 2013 at 8:12 AM, Pekka Paalanen wrote:
> On Sun, 5 May 2013 22:06:49 +0200
> Tom Gundersen wrote:
>
>> Hi Pekka,
>>
>> I'm trying to make Weston work nicely on Raspberry Pi under ArchLinux
>> ARM, and was pointed to Collabora's pkg-config files [0] from the
>> Wayland wiki [1]. I c
The Y of the primaries can be used as alternative method of specifying
the whitepoint. (convert the 3 Yxy colors to XYZ, add them, then convert
back to Yxy and the xy is the whitepoint, I think).
I think the reason rgb sets are specfied as 4 pairs of xy (the three
primaries and the whitepoint)
Pekka Paalanen wrote:
On Fri, 03 May 2013 12:11:17 -0700
Bill Spitzak wrote:
Pekka Paalanen wrote:
What chip do you have in mind, that can do arbitrary
matrix-based transforms during an overlay scanout?
That just means the surface cannot use the overlay, or the compositor
has to use an in
Pekka Paalanen wrote:
sending pointer axis events (i.e. scroll wheel) to the window with
the keyboard focus is... unexplored. If it is ok to send axis events
outside of a wl_pointer.enter/leave pair, then it's perfectly doable.
Is it, I don't know. I don't see a reason it wouldn't work, if clien
On 6 May 2013 14:48, Todd Showalter wrote:
> On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
>> Into wl_seat, we should add a capability bit for gamepad. When the bit
>> is set, a client can send wl_seat::get_gamepad_manager request, which
>> creates a new wl_gamepad_manager object. (Do we
On Mon, May 6, 2013 at 8:36 AM, Pekka Paalanen wrote:
> Into wl_seat, we should add a capability bit for gamepad. When the bit
> is set, a client can send wl_seat::get_gamepad_manager request, which
> creates a new wl_gamepad_manager object. (Do we actually need a
> capability bit?)
There ar
On Mon, 6 May 2013 11:01:28 +0100
Daniel Stone wrote:
> Hi,
>
> On 5 May 2013 17:55, Pekka Paalanen wrote:
> > On Fri, 3 May 2013 17:42:20 +0100
> > Daniel Stone wrote:
> >> tl;dr: wl_seat has a very specific meaning of a set of devices with
> >> one focus, please don't abuse it.
> >
> > I'm n
On 2013-05-06, at 2:54 AM, Pekka Paalanen wrote:
>>I don't think there's any problem in principle with the gamepad
>> events being delivered to the same client that has keyboard focus.
>> The only annoying thing is if (in a multiplayer game) someone can
>> screw you by sending you a well-time
Hi,
On 5 May 2013 17:55, Pekka Paalanen wrote:
> On Fri, 3 May 2013 17:42:20 +0100
> Daniel Stone wrote:
>> tl;dr: wl_seat has a very specific meaning of a set of devices with
>> one focus, please don't abuse it.
>
> I'm not too clear on what it is.
>
> In a wl_seat, we have one kbd focus, and o
On Mon, 6 May 2013 09:07:01 +0200
David Herrmann wrote:
> Hi Pekka
>
> On Mon, May 6, 2013 at 8:54 AM, Pekka Paalanen wrote:
> > On Sun, 5 May 2013 15:27:54 -0400
> > Todd Showalter wrote:
> >> Having given it some thought, I'd be inclined to be cautious about
> >> how much you consider th
Hi Pekka
On Mon, May 6, 2013 at 8:54 AM, Pekka Paalanen wrote:
> On Sun, 5 May 2013 15:27:54 -0400
> Todd Showalter wrote:
>> Having given it some thought, I'd be inclined to be cautious about
>> how much you consider the gamepad-with-builtin-keyboard case. They
>> really made those things
20 matches
Mail list logo
