> When the client receives a mouse-down event, it knows it is in this mode.
> The mode is exited when all the mouse buttons are released.
>
> While in this mode the mouse position is reported as though the user is
> dragging over a very large torus surface (ie it wraps at very large
> integers), th
On Wed, Apr 24, 2013 at 5:03 PM, Rick Yorgason wrote:
>> The core of my argument here is that there should be a standard
>> gamepad coming through the event system, much like the standard mouse
>> does. The standard gamepad would be:
>
> For reference, in the Windows XP days joystick input
Todd Showalter writes:
> The core of my argument here is that there should be a standard
> gamepad coming through the event system, much like the standard mouse
> does. The standard gamepad would be:
For reference, in the Windows XP days joystick input was done with
DirectInput, which was
On 04/23/2013 11:26 PM, David Herrmann wrote:
I'm currently looking into an interface that provides file-descriptors
for wl_keyboard/wl_mouse for clients. The FDs are muted (EVIOCMUTE
proposed on linux-input by krh) while clients are inactive and unmuted
when they get input focus. This is basica
On 04/24/2013 12:12 AM, Pekka Paalanen wrote:
How do you make the cursor not blink when switching between the real and
fake one?
Draw your own first, then hide the cursor, hope that there are no
surface transforms in effect.
That does not work if the cursor has any transparency. The
paintin
On Wed, Apr 24, 2013 at 11:03 AM, Jason Ekstrand wrote:
> I realize that my little Android project shouldn't be the sole driver of
> protocol decisions, but I don't think that is the only case where game
> controller events would come from something that's not evdev. As another
> example, people
On Wed, Apr 24, 2013 at 9:41 AM, Todd Showalter wrote:
> On Wed, Apr 24, 2013 at 2:26 AM, David Herrmann
> wrote:
>
> > That's a known problem that isn't easy to fix. Of course, we can
> > adjust the kernel driver, but this breaks applications that expect the
> > current behavior. The problem I s
On Wed, Apr 24, 2013 at 2:26 AM, David Herrmann wrote:
> That's a known problem that isn't easy to fix. Of course, we can
> adjust the kernel driver, but this breaks applications that expect the
> current behavior. The problem I see is that we never paid enough
> attention how keys are mapped whe
This allows users to change the assigned display profile in GNOME (using
gnome-control-center) or KDE (using colord-kde) and also allows the profiling
tools to correctly inhibit the calibration state whilst measuring the native
screen response.
---
configure.ac| 10 ++
src/Makefile.am | 9 +
ICC profiles can now be specified in weston.ini for each output, or a CMS
implementation can optionally loaded from a pluggable module.
---
configure.ac | 7 +++
src/Makefile.am | 6 ++-
src/cms.c| 106 +
src/cms.h| 84 +
At the moment we're only extracting interesting strings. We have to be quite
careful parsing the EDID data, as vendors like to do insane things.
The original EDID parsing code was written by me for gnome-color-manager.
---
src/compositor-drm.c | 149 +++
These three patches are the combined work of the EDID feature and
the CMS feature. With all three patches applied to master output devices are
registered with colord. Color correction and profiling works when using
clients such as colord-kde or gnome-color-manager.
In the future, this framework wi
On 04/24/2013 02:02 PM, Richard Hughes wrote:
> On 24 April 2013 12:42, Emilio Pozuelo Monfort wrote:
>> This is exposed in the weston SDK (compositor.h is a public header). This
>> patch
>> breaks the ABI, but I don't think we have promised to keep it stable for now.
>
> I didn't know we offere
On 24 April 2013 12:42, Emilio Pozuelo Monfort wrote:
> This is exposed in the weston SDK (compositor.h is a public header). This
> patch
> breaks the ABI, but I don't think we have promised to keep it stable for now.
I didn't know we offered any king of ABI/API stability in Weston. If
we do, we
On 04/23/2013 05:37 PM, Rob Bradford wrote:
> On Mon, Apr 22, 2013 at 12:57:03PM +0100, Richard Hughes wrote:
>> ---
>> src/compositor-drm.c | 1 +
>> src/compositor.h | 2 +-
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
>> i
On Tue, Apr 23, 2013 at 08:32:28PM +0100, Richard Hughes wrote:
> On 23 April 2013 16:37, Rob Bradford wrote:
>
> > Are you intending to expose this through the wayland protocol? If so
> > have you considered how this ambiguity might be avoided.
>
> "serial_number"?
Sounds good to me!
Rob
On Wed, 24 Apr 2013 08:26:19 +0200
David Herrmann wrote:
> Hi Todd
>
> On Tue, Apr 23, 2013 at 4:12 PM, Todd Showalter wrote:
> > On Tue, Apr 23, 2013 at 7:25 AM, Pekka Paalanen wrote:
> >
> >> what you describe here is very much a keymap-like database for game
> >> controllers: translating fr
On Tue, 23 Apr 2013 08:47:59 -0700
Bill Spitzak wrote:
> On 04/23/2013 12:11 AM, Pekka Paalanen wrote:
>
> > Here's a lot simpler solution for non-jittery dragging of objects: just
> > hide the pointer cursor, when starting the move. If you still want the
> > pointer cursor visible, draw it your
18 matches
Mail list logo
