On Fri, 2015-11-20 at 18:41 +0100, Olivier Fourdan wrote:
> diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> index f97f100..9101382 100644
> --- a/hw/xwayland/xwayland-output.c
> +++ b/hw/xwayland/xwayland-output.c
> @@ -164,9 +164,6 @@ update_screen_size(struct xwl_out
On Fri, 2015-11-20 at 12:39 +, Emil Velikov wrote:
> > The tslib question is really what do we do with kdrive. Xfake seems
> > pretty useless given Xvfb, and the only win for Xfbdev over Xorg+fbdev
> > is marginally smaller footprint. On the other hand Xephyr is a hugely
> > important tool,
On 2015-11-17 15:10, Adam Jackson wrote:
> On Wed, 2015-11-11 at 22:02 -0800, Keith Packard wrote:
>> This allows the server to call GetTimeInMillis() after each request is
>> processed to avoid needing setitimer. -dumbSched now turns off the
>> setitimer.
>
> I'm not sure there are real systems w
When unplugging an output, it's still listed in xrandr and the size
of the root window still includes the removed output.
The RR output should be destroyed when its Wayland counterpart is
destroyed and the screen dimensions must be updated in both the done
and the destroy handlers.
Bugzilla: http
Otherwise the server may try to draw onto the root window when closing
down, while when rootless the root window which has no storage, thus
causing memory corruption.
Thanks to Adam Jackson for helping tracking this down!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93045
Signed-off-by
When unplugging an output, it's still listed in xrandr and the size
of the root window still includes the removed output.
The RR output should be destroyed when its Wayland counterpart is
destroyed and the screen dimensions must be updated in both the done
and the destroy handlers.
Bugzilla: http
> Date: Fri, 20 Nov 2015 17:43:44 +0100
> From: Francois Tigeot
>
> On Thu, Nov 19, 2015 at 10:06:51AM -0500, Adam Jackson wrote:
> > On Thu, 2015-11-19 at 12:07 +, Emil Velikov wrote:
> >
> > Removing fbdevhw would break mga and r128 and a few others on non-x86.
>
> FWIW, I have removed su
On Thu, Nov 19, 2015 at 10:06:51AM -0500, Adam Jackson wrote:
> On Thu, 2015-11-19 at 12:07 +, Emil Velikov wrote:
>
> Removing fbdevhw would break mga and r128 and a few others on non-x86.
FWIW, I have removed support for old legacy drm drivers one year ago
in DragonFly. Nobody even noticed
Add a flag to DeviceEvents, giving the source of the event. Currently
this only supports a 'normal' flag, but will be used later to add a
'focus-in' flag, noting events synthesised from key/button arrays on
focus-in notifications.
Signed-off-by: Daniel Stone
---
dix/getevents.c | 24 +++
Hi,
One year later, a follow-up to:
http://lists.x.org/archives/xorg-devel/2014-November/044627.html
This aims to support the XWayland equivalent of KeymapNotify correctly,
in particular fixing Alt-Tab. Without this patch, when you Alt-Tab to an
XWayland client, it receives Alt as a fully-fledged
Add a new event source type for keypress events synthesised from focus
notifications (e.g. KeymapNotify from the parent server, when running
nested). This is used to keep the keys-down array in sync with the host
server's, without sending actual keypress events to clients.
Signed-off-by: Daniel St
Move the giant state machine which maps from a key action to actually
running the filters into a separate function, to be used when adding
KeyFocusIn.
Signed-off-by: Daniel Stone
Tested-by: Giulio Camuffo
Reviewed-by: Peter Hutterer
---
xkb/xkbActions.c | 144 +-
wl_keyboard::enter is the equivalent of FocusIn + KeymapNotify: it
notifies us that the surface/window has now received the focus, and
provides us a set of keys which are currently down.
We should use these keys to update the current state, but not to send
any events to clients.
Signed-off-by: Da
On 19 November 2015 at 15:06, Adam Jackson wrote:
> On Thu, 2015-11-19 at 12:07 +, Emil Velikov wrote:
>
>> It seems that most of the use-cases are related to the int10 module.
>> To make things even more interesting - when using the Sun/Oracle
>> compiler many additional functions will end up
Hi,
On 20-11-15 03:29, Peter Hutterer wrote:
The server uses pInfo->major/minor to detect if another device is using the
same path for a logind-controlled fd. If so, it reuses that device's
pInfo->fd and sets the "fd" option to that value.
That pInfo->fd is the libinput epollfd though, not the
15 matches
Mail list logo