Re: using uinput connect X to proprietary (TCP based) keyboard endpoint
On 10/16/2014 08:12 AM, Peter Hutterer wrote:
On Thu, Oct 16, 2014 at 04:48:37AM +0200, arne.ad...@t-online.de wrote:
Hi,
I am trying to integrate a proprietary keyboard, sending linux scancodes via
TCP.
My idea is to use uinput to forward the received keycodes to locally running
applications (including the x server).
In my xorg.conf I have the following section:
Section InputDevice
# to enable user defined virtual keyboard
Identifier Keyboard1
Option Device /dev/input/event14
Driver evdev
EndSection
where event14 is the event queue associated to the uinput simulated device.
I do see the scancodes sent from my device with both commands:
- xinput test-xi2 --root
- showkey -s
However I am not able to intercept the keyboard events in this simple X
application
int main(int argc, char** argv)
{
Display* display = XOpenDisplay(NULL);
Window window = XCreateSimpleWindow(display, RootWindow(display, 0), 1, 1,
500, 500,
0, BlackPixel(display, 0),
BlackPixel(display, 0));
XSelectInput(display, window, KeyPressMask | KeyReleaseMask);
XMapWindow(display, window);
add a XFlush() here, that should do the trick.
XNextEvent implicitly flushes.
Cheers,
Peter
XEvent report;
while (1)
{
XNextEvent(display, report);
switch (report.type)
{
case KeyRelease:
printf(got a KeyRelease event: %d, %d\n, report.xkey.keycode,
report.xkey.state);
break;
case KeyPress:
printf(got a KeyPress event: %d, %d\n, report.xkey.keycode,
report.xkey.state);
break;
default:
printf(got a %d event\n, report.type);
break;
}
}
XFlush(display);
sleep(5);
return (EXIT_SUCCESS);
}
--
Aaron
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s
kdrive udev/seat support
I'm adding udev/seat support to kdrive* in order to support running Xfbdev on a picolcdfb device (USB mono LCD + keys) as an auxiliary video display on which I'll run a graphical system monitor like Conky. Right now I have basic -seat support working, when !seat0 vt switching is disabled and it uses the appropriate fb device according to udev. This is enough to get it working for me since I can now just start Xfbdev with the appropriate evdev for input, as I've not yet implemented seat based input device configuration. Is there any interest in getting this upstream? Shall I post the work done so far, or get the input device configuration finished first? *I would have just used Xorg, but the fbdev driver doesn't support MONO01 visuals, it seemed easier to add the missing -seat support to kdrive. signature.asc Description: This is a digitally signed message part ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Is this a hardware or a software problem?
Hi, is it possible to know where (or which) is the source of the problem from this info: http://pastebin.com/yX1W6jcx ? Those are the logs of the moment when the OS (an updated debian on a 10 years old pc) hanged and put me out of session (I had to re-log to my user account). This has been passing for weeks, randomly, and usually the system hangs and doesn't respond to nothing (Ctrl+Alt+F2, etx) so you have to reboot. Thanks a lot! ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: tile property contents
On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote: On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote: On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@nvidia.com wrote: I assume the TILE property described below would be per-connector? It looks like this would handle the DP MST tiled display case. At the risk of trying to solve too much at once: There are also configurations where users configure multiple heads to drive power walls that they want to be treated as one logical monitor, similar to the DP MST tiled display case. Normally, those powerwall configurations don't have any layout information from the monitors themselves, and the layout is configured by the user. Would it be appropriate for users to be able to set the TILE property in that sort of scenario? For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc should be expressed in pixels rather than tiles? Sometimes, the tiles in those powerwalls may not all have the same resolution, or may be configured with overlap. I suppose that would make the TILE configuration specific to the current modetimings on each tile... Why can't users just set that mode? Sure, users can set the mode, but: * Part of what the TILE property conveys is how monitors should be grouped for purposes of window maximization. Users don't have a great way to express that today, that I'm aware of. My understanding for why we want the TILE property is to avoid to duplicate displayId parsing over every bit of userspace (and the fbcon stuff in the kernel) interested in it. Imo the proper way for userspace is to always just inherit whatever modeset config is already there. * Users might configure the mode they want, but then gnome-settings-daemon may come along later and decide it knows better than the user how things should be configured. One scenario where this comes up is: (a) user meticulously configures his power wall (b) user hotplugs another monitor I've definitely seen cases where window managers will try to be clever in response to a hotplug, and clobber the user's current configuration. If the TILE property conveyed how some set of monitors was supposed to be grouped, that would hopefully give window managers additional information, such that they would know to keep that group intact. Well, imnsho gnome display control center is a bit too opiniated about automatic modeset changes. If their assumption is that they always know perfectly what the user wants upon hotplug I really don't want to work around this in the kernel. Since for everything else than a laptop + beamer gnome panel always pisses me off ;-) I think gnome should just ask the user what it wants if there's more than 2 physical displays (treating a tiled 4k screen as one ofc), since there's really no way at all to tell. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH:font/util] Update map-JISX0201.1976-0 to current version from Unicode Consortium
Hi, On 08/26/2014 04:06 AM, Alan Coopersmith wrote: New version is exactly as downloaded on August 25, 2014 from ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/JIS0201.TXT Does not change mappings, only changes comments (including license notice). Reported-by: AGinsberg on #xorg-devel irc Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Looks good: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans --- COPYING |2 +- map-JISX0201.1976-0 | 42 ++ 2 files changed, 27 insertions(+), 17 deletions(-) diff --git a/COPYING b/COPYING index 0ff9042..8febe74 100644 --- a/COPYING +++ b/COPYING @@ -103,7 +103,7 @@ from the copyright holders. -Copyright (c) 1991-2003 Unicode, Inc. All Rights reserved. +Copyright (c) 1991-2011 Unicode, Inc. All Rights reserved. This file is provided as-is by Unicode, Inc. (The Unicode Consortium). No claims are made as to fitness for any particular purpose. No diff --git a/map-JISX0201.1976-0 b/map-JISX0201.1976-0 index 87e9e94..ca18c42 100644 --- a/map-JISX0201.1976-0 +++ b/map-JISX0201.1976-0 @@ -1,13 +1,11 @@ # #Name: JIS X 0201 (1976) to Unicode 1.1 Table #Unicode version: 1.1 -#Table version:0.9 +#Table version:1.0 #Table format: Format A -#Date: 8 March 1994 -#Authors: Glenn Adams gl...@metis.com -# John H. Jenkins john_jenk...@taligent.com +#Date: 2011 October 14 # -#Copyright (c) 1991-1994 Unicode, Inc. All Rights reserved. +#Copyright (c) 1994-2011 Unicode, Inc. All Rights reserved. # #This file is provided as-is by Unicode, Inc. (The Unicode Consortium). #No claims are made as to fitness for any particular purpose. No @@ -17,17 +15,22 @@ #remedy for any claim will be exchange of defective media within 90 #days of receipt. # -#Recipient is granted the right to make copies in any form for -#internal distribution and to freely use the information supplied -#in the creation of products supporting Unicode. Unicode, Inc. -#specifically excludes the right to re-distribute this file directly -#to third parties or other organizations whether for profit or not. +# Unicode, Inc. hereby grants the right to freely use the information +# supplied in this file in the creation of products supporting the +# Unicode Standard, and to make copies of this file in any form for +# internal or external distribution as long as this notice remains +# attached. # #General notes: # -#This table contains the data the Unicode Consortium has on how -#single-byte JIS X 0201 characters map into Unicode 1.1 -#(ISO/IEC 10646:1-1993 UCS-2). +# +# This table contains one set of mappings from JIS X 0201 into Unicode. +# Note that these data are *possible* mappings only and may not be the +# same as those used by actual products, nor may they be the best suited +# for all uses. For more information on the mappings between various code +# pages incorporating the repertoire of JIS X 0201 and Unicode, consult the +# VENDORS mapping data. +# # #Format: Three tab-separated columns #Column #1 is the shift JIS code (in hex as 0xXX) @@ -36,11 +39,18 @@ # #The entries are in JIS order # -# These mappings are provisional, pending definition of -# official mappings by Japanese standards bodies. +# Revision History: +# +#[v1.0, 2011 October 14] +#Updated terms of use to current wording. +#Updated contact information. +#No changes to the mapping data. # -#Any comments or problems, contact john_jenk...@taligent.com +#[v0.9, 8 March 1994] +#First release. # +# Use the Unicode reporting form http://www.unicode.org/reporting.html +#for any questions or comments or to report errors in the data. # 0x20 0x0020 # SPACE 0x21 0x0021 # EXCLAMATION MARK ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libXau] XauGet*AuthByAddr: add new variants which allow passing an explicit authorization file path.
Hi,
On 10/20/2014 02:19 PM, Laércio de Sousa wrote:
It will allow extending functions like Xlib's XOpenDislay() or XCB's
xcb_connect()
to allow passing an explicit authorization file path (they already allow
passing
an explicit display number). This can be useful in exceptional cases where
XAUTHORITY environment variable is not set at the time a X11 client is
launched.
Currently, a X11 client that needs to connect to a display with a given
authorization file needs to set XAUTHORITY itself (if not yet set) before
connecting.
Signed-off-by: Laércio de Sousa laercioso...@sme-mogidascruzes.sp.gov.br
Code looks good to me and is:
Acked-by: Hans de Goede hdego...@redhat.com
I think this should get a second look by someone more familiar with the Xau code
though, so I'll leave merging this up to someone else.
Regards,
Hans
---
AuGetAddr.c | 38 --
AuGetBest.c | 36 +++--
include/X11/Xauth.h | 45
man/Xau.man | 20 ++--
man/XauGetAuthByAddrWithFile.man | 1 +
man/XauGetBestAuthByAddrWithFile.man | 1 +
6 files changed, 135 insertions(+), 6 deletions(-)
create mode 100644 man/XauGetAuthByAddrWithFile.man
create mode 100644 man/XauGetBestAuthByAddrWithFile.man
diff --git a/AuGetAddr.c b/AuGetAddr.c
index 6f5fe16..3aeffa4 100644
--- a/AuGetAddr.c
+++ b/AuGetAddr.c
@@ -33,7 +33,8 @@ in this Software without prior written authorization from
The Open Group.
#define binaryEqual(a, b, len) (memcmp(a, b, len) == 0)
Xauth *
-XauGetAuthByAddr (
+XauGetAuthByAddrWithFile (
+_Xconst char*auth_file,
#if NeedWidePrototypes
unsigned int family,
unsigned int address_length,
@@ -59,7 +60,7 @@ _Xconst char* name)
char*auth_name;
Xauth *entry;
-auth_name = XauFileName ();
+auth_name = auth_file ? auth_file : XauFileName ();
if (!auth_name)
return NULL;
if (access (auth_name, R_OK) != 0) /* checks REAL id */
@@ -100,3 +101,36 @@ _Xconst char*name)
(void) fclose (auth_file);
return entry;
}
+
+Xauth *
+XauGetAuthByAddr (
+#if NeedWidePrototypes
+unsigned int family,
+unsigned int address_length,
+#else
+unsigned short family,
+unsigned short address_length,
+#endif
+_Xconst char*address,
+#if NeedWidePrototypes
+unsigned int number_length,
+#else
+unsigned short number_length,
+#endif
+_Xconst char*number,
+#if NeedWidePrototypes
+unsigned int name_length,
+#else
+unsigned short name_length,
+#endif
+_Xconst char*name)
+{
+XauGetAuthByAddrWithFile (NULL,
+ family,
+ address_length,
+ address,
+ number_length,
+ number,
+ name_length,
+ name);
+}
diff --git a/AuGetBest.c b/AuGetBest.c
index 5556559..73ee907 100644
--- a/AuGetBest.c
+++ b/AuGetBest.c
@@ -41,7 +41,8 @@ in this Software without prior written authorization from
The Open Group.
#define binaryEqual(a, b, len) (memcmp(a, b, len) == 0)
Xauth *
-XauGetBestAuthByAddr (
+XauGetBestAuthByAddrWithFile (
+_Xconst char*auth_file,
#if NeedWidePrototypes
unsigned int family,
unsigned int address_length,
@@ -71,7 +72,7 @@ XauGetBestAuthByAddr (
unsigned short fully_qual_address_length;
#endif
-auth_name = XauFileName ();
+auth_name = auth_file ? auth_file : XauFileName ();
if (!auth_name)
return NULL;
if (access (auth_name, R_OK) != 0) /* checks REAL id */
@@ -161,3 +162,34 @@ XauGetBestAuthByAddr (
(void) fclose (auth_file);
return best;
}
+
+Xauth *
+XauGetBestAuthByAddr (
+#if NeedWidePrototypes
+unsigned int family,
+unsigned int address_length,
+#else
+unsigned short family,
+unsigned short address_length,
+#endif
+_Xconst char*address,
+#if NeedWidePrototypes
+unsigned int number_length,
+#else
+unsigned short number_length,
+#endif
+_Xconst char*number,
+int types_length,
+char** types,
+_Xconst int* type_lengths)
+{
+XauGetBestAuthByAddrWithFile (NULL,
+ family,
+ address_length,
+ address,
+ number_length,
+ number,
+ types_length,
+ types,
+ type_lengths);
+}
diff --git a/include/X11/Xauth.h b/include/X11/Xauth.h
index
[PATCH font/encodings] jisx0201.1976-0.enc: Add undefined mapping for 0x7f - 0xa0 range
From: Akira TAGOH ta...@redhat.com The jisx0201 encoding has a hole in it in the 0x7f - 0xa0 range, see: http://en.wikipedia.org/wiki/JIS_X_0201 The document for the format of the encoding files says: Codes not listed are assumed to map through the identity (i.e. to the same numerical value). In order to override this default mapping, you may specify a range of codes to be undefined by using an `UNDEFINE' line jisx0201.1976-0.enc was not doing this, causing all the codes on the range to be mapped 1:1. This specifically is causing problems for ttmkfdir, which checks that a font covers (most of) an encoding before adding a line for that encoding to fonts.scale, and the hole not properly being undefined causes this check to fail for atleast the Sazanami fonts. Cc: Akira TAGOH ta...@redhat.com BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1009350 Signed-off-by: Hans de Goede hdego...@redhat.com --- large/jisx0201.1976-0.enc | 1 + 1 file changed, 1 insertion(+) diff --git a/large/jisx0201.1976-0.enc b/large/jisx0201.1976-0.enc index 915d50c..328bc7a 100644 --- a/large/jisx0201.1976-0.enc +++ b/large/jisx0201.1976-0.enc @@ -68,6 +68,7 @@ ENDMAPPING STARTMAPPING unicode 0x5C 0x00A5 # YEN SIGN 0x7E 0x203E # OVERLINE +UNDEFINE 0x7F0xA0 0x00A1 0x00DF 0xFF61 ENDMAPPING STARTMAPPING cmap 1 1 -- 2.1.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/4] xwayland: Implement the wl_touch interface
A DeviceIntPtr with touch valuators is also created in order to deliver
the translated touch events. The lifetime of xwl_touch structs is tied
to the wayland ones, finishing in either wl_touch.up() or wl_touch.cancel()
Signed-off-by: Carlos Garnacho carl...@gnome.org
---
hw/xwayland/xwayland-input.c | 206 ++-
hw/xwayland/xwayland.h | 2 +
2 files changed, 205 insertions(+), 3 deletions(-)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index b661921..0aead8f 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -139,6 +139,61 @@ xwl_keyboard_proc(DeviceIntPtr device, int what)
return BadMatch;
}
+static int
+xwl_touch_proc(DeviceIntPtr device, int what)
+{
+#define NTOUCHPOINTS 20
+#define NBUTTONS 1
+#define NAXES 2
+struct xwl_seat *xwl_seat = device-public.devicePrivate;
+Atom btn_labels[NBUTTONS] = { 0 };
+Atom axes_labels[NAXES] = { 0 };
+BYTE map[NBUTTONS + 1] = { 0 };
+
+switch (what) {
+case DEVICE_INIT:
+device-public.on = FALSE;
+
+axes_labels[0] = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_MT_POSITION_X);
+axes_labels[1] = XIGetKnownProperty(AXIS_LABEL_PROP_ABS_MT_POSITION_Y);
+
+if (!InitValuatorClassDeviceStruct(device, NAXES, axes_labels,
+ GetMotionHistorySize(), Absolute))
+return BadValue;
+
+if (!InitButtonClassDeviceStruct(device, NBUTTONS, btn_labels, map))
+return BadValue;
+
+if (!InitTouchClassDeviceStruct(device, NTOUCHPOINTS,
+XIDirectTouch, NAXES))
+return BadValue;
+
+/* Valuators */
+/* FIXME: devices might be mapped to a single wl_output */
+InitValuatorAxisStruct(device, 0, axes_labels[0],
+ 0, xwl_seat-xwl_screen-width,
+ 1, 0, 1, Absolute);
+InitValuatorAxisStruct(device, 1, axes_labels[1],
+ 0, xwl_seat-xwl_screen-height,
+ 1, 0, 1, Absolute);
+return Success;
+
+case DEVICE_ON:
+device-public.on = TRUE;
+return Success;
+
+case DEVICE_OFF:
+case DEVICE_CLOSE:
+device-public.on = FALSE;
+return Success;
+}
+
+return BadMatch;
+#undef NAXES
+#undef NBUTTONS
+#undef NTOUCHPOINTS
+}
+
static void
pointer_handle_enter(void *data, struct wl_pointer *pointer,
uint32_t serial, struct wl_surface *surface,
@@ -471,6 +526,129 @@ static const struct wl_keyboard_listener
keyboard_listener = {
keyboard_handle_modifiers,
};
+static struct xwl_touch *
+xwl_seat_lookup_touch(struct xwl_seat *xwl_seat, int32_t id)
+{
+struct xwl_touch *xwl_touch, *next_xwl_touch;
+
+xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
+ xwl_seat-touches, link_touch) {
+if (xwl_touch-id == id)
+return xwl_touch;
+}
+
+return NULL;
+}
+
+static void
+xwl_touch_send_event(struct xwl_touch *xwl_touch,
+ struct xwl_seat *xwl_seat, int type)
+{
+int32_t dx, dy;
+ValuatorMask mask;
+
+dx = xwl_touch-window-window-drawable.x;
+dy = xwl_touch-window-window-drawable.y;
+
+valuator_mask_zero(mask);
+valuator_mask_set(mask, 0, dx + xwl_touch-x);
+valuator_mask_set(mask, 1, dy + xwl_touch-y);
+QueueTouchEvents(xwl_seat-touch, type, xwl_touch-id, 0, mask);
+}
+
+static void
+touch_handle_down(void *data, struct wl_touch *wl_touch,
+ uint32_t serial, uint32_t time,
+ struct wl_surface *surface,
+ int32_t id, wl_fixed_t sx_w, wl_fixed_t sy_w)
+{
+struct xwl_seat *xwl_seat = data;
+struct xwl_touch *xwl_touch;
+
+if (surface == NULL)
+return;
+
+xwl_touch = calloc(sizeof *xwl_touch, 1);
+if (xwl_touch == NULL) {
+ErrorF(touch_handle_down ENOMEM);
+return;
+}
+
+xwl_touch-window = wl_surface_get_user_data(surface);
+xwl_touch-id = id;
+xwl_touch-x = wl_fixed_to_int(sx_w);
+xwl_touch-y = wl_fixed_to_int(sy_w);
+xorg_list_add(xwl_touch-link_touch, xwl_seat-touches);
+
+xwl_touch_send_event(xwl_touch, xwl_seat, XI_TouchBegin);
+}
+
+static void
+touch_handle_up(void *data, struct wl_touch *wl_touch,
+uint32_t serial, uint32_t time, int32_t id)
+{
+struct xwl_touch *xwl_touch;
+struct xwl_seat *xwl_seat = data;
+
+xwl_touch = xwl_seat_lookup_touch(xwl_seat, id);
+
+if (!xwl_touch)
+return;
+
+xwl_touch_send_event(xwl_touch, xwl_seat, XI_TouchEnd);
+xorg_list_del(xwl_touch-link_touch);
+free(xwl_touch);
+}
+
+static void
+touch_handle_motion(void *data, struct wl_touch *wl_touch,
+uint32_t time, int32_t id,
+wl_fixed_t sx_w, wl_fixed_t sy_w)
+{
+
[PATCH 3/4] xwayland: Remove related touchpoints when unrealizing windows
These sequences are forgotten to all purposes.
Signed-off-by: Carlos Garnacho carl...@gnome.org
---
hw/xwayland/xwayland-input.c | 14 ++
hw/xwayland/xwayland.c | 6 +++---
hw/xwayland/xwayland.h | 2 ++
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 0aead8f..4f39032 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -870,6 +870,20 @@ xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int
x, int y)
}
void
+xwl_seat_clear_touch(struct xwl_seat *xwl_seat, WindowPtr window)
+{
+struct xwl_touch *xwl_touch, *next_xwl_touch;
+
+xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
+ xwl_seat-touches, link_touch) {
+if (xwl_touch-window-window == window) {
+xorg_list_del(xwl_touch-link_touch);
+free(xwl_touch);
+}
+}
+}
+
+void
InitInput(int argc, char *argv[])
{
ScreenPtr pScreen = screenInfo.screens[0];
diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c
index 9132969..f532ebc 100644
--- a/hw/xwayland/xwayland.c
+++ b/hw/xwayland/xwayland.c
@@ -287,10 +287,10 @@ xwl_unrealize_window(WindowPtr window)
xwl_screen = xwl_screen_get(screen);
xorg_list_for_each_entry(xwl_seat, xwl_screen-seat_list, link) {
-if (!xwl_seat-focus_window)
-continue;
-if (xwl_seat-focus_window-window == window)
+if (xwl_seat-focus_window xwl_seat-focus_window-window == window)
xwl_seat-focus_window = NULL;
+
+xwl_seat_clear_touch(xwl_seat, window);
}
screen-UnrealizeWindow = xwl_screen-UnrealizeWindow;
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index 537cfbc..5a82103 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -162,6 +162,8 @@ void xwl_seat_set_cursor(struct xwl_seat *xwl_seat);
void xwl_seat_destroy(struct xwl_seat *xwl_seat);
+void xwl_seat_clear_touch(struct xwl_seat *xwl_seat, WindowPtr window);
+
Bool xwl_screen_init_output(struct xwl_screen *xwl_screen);
struct xwl_output *xwl_output_create(struct xwl_screen *xwl_screen,
--
2.1.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xwayland 0/4] Implement wl_touch
Hi!, Here's a few patches that add touch event support to xwayland. It has still a FIXME around device range/resolution if a non-identity matrix applies, which I'm a bit unsure how to handle. But this makes things work for the most common cases, which is an improvement to the status quo. Cheers, Carlos hw/xwayland/xwayland-input.c | 298 --- hw/xwayland/xwayland.c | 6 +- hw/xwayland/xwayland.h | 13 ++ 3 files changed, 298 insertions(+), 19 deletions(-) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/4] xwayland: Add xwl_touch struct
This struct holds information about each individual, ongoing touchpoint.
A list of these is held by the xwl_seat.
Signed-off-by: Carlos Garnacho carl...@gnome.org
---
hw/xwayland/xwayland-input.c | 10 ++
hw/xwayland/xwayland.h | 9 +
2 files changed, 19 insertions(+)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index b8c543c..b661921 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -576,11 +576,21 @@ create_input_device(struct xwl_screen *xwl_screen,
uint32_t id)
xwl_seat-cursor = wl_compositor_create_surface(xwl_screen-compositor);
wl_seat_add_listener(xwl_seat-seat, seat_listener, xwl_seat);
wl_array_init(xwl_seat-keys);
+
+xorg_list_init(xwl_seat-touches);
}
void
xwl_seat_destroy(struct xwl_seat *xwl_seat)
{
+struct xwl_touch *xwl_touch, *next_xwl_touch;
+
+xorg_list_for_each_entry_safe(xwl_touch, next_xwl_touch,
+ xwl_seat-touches, link_touch) {
+xorg_list_del(xwl_touch-link_touch);
+free(xwl_touch);
+}
+
RemoveDevice(xwl_seat-pointer, FALSE);
RemoveDevice(xwl_seat-keyboard, FALSE);
wl_seat_destroy(xwl_seat-seat);
diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h
index bfffa71..3920e01 100644
--- a/hw/xwayland/xwayland.h
+++ b/hw/xwayland/xwayland.h
@@ -107,6 +107,13 @@ struct xwl_window {
#define MODIFIER_META 0x01
+struct xwl_touch {
+struct xwl_window *window;
+int32_t id;
+int x, y;
+struct xorg_list link_touch;
+};
+
struct xwl_seat {
DeviceIntPtr pointer;
DeviceIntPtr keyboard;
@@ -122,6 +129,8 @@ struct xwl_seat {
struct xorg_list link;
CursorPtr x_cursor;
+struct xorg_list touches;
+
wl_fixed_t horizontal_scroll;
wl_fixed_t vertical_scroll;
uint32_t scroll_time;
--
2.1.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/4] xwayland: Make the XYToWindowProc implementation aware of touchpoints
For these, we must first lookup the DIX sequence from the Sprite, we can
then lookup the DDX ID/xwl_touch from xwayland's touch device.
Signed-off-by: Carlos Garnacho carl...@gnome.org
---
hw/xwayland/xwayland-input.c | 68 +++-
1 file changed, 55 insertions(+), 13 deletions(-)
diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 4f39032..2d3192f 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -838,29 +838,71 @@ DDXRingBell(int volume, int pitch, int duration)
{
}
-static WindowPtr
-xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
+static int32_t
+lookup_sprite_touch_client_id (SpritePtr sprite)
{
-struct xwl_seat *xwl_seat = NULL;
DeviceIntPtr device;
+int i;
for (device = inputInfo.devices; device; device = device-next) {
-if (device-deviceProc == xwl_pointer_proc
-device-spriteInfo-sprite == sprite) {
-xwl_seat = device-public.devicePrivate;
-break;
+if (!device-touch)
+continue;
+
+for (i = 0; i device-touch-num_touches; i++) {
+TouchPointInfoPtr ti = device-touch-touches + i;
+
+if (sprite == ti-sprite)
+return ti-client_id;
}
}
-if (xwl_seat == NULL) {
-/* XTEST device */
-sprite-spriteTraceGood = 1;
-return sprite-spriteTrace[0];
+return 0;
+}
+
+static struct xwl_touch *
+xwl_touch_lookup_from_client_id (struct xwl_seat *xwl_seat, int32_t client_id)
+{
+DeviceIntPtr touch = xwl_seat-touch;
+int i;
+
+for (i = 0; i touch-last.num_touches; i++) {
+DDXTouchPointInfoPtr ddx_ti = touch-last.touches + i;
+
+if (ddx_ti-client_id == client_id)
+return xwl_seat_lookup_touch(xwl_seat, ddx_ti-ddx_id);
+}
+
+return NULL;
+}
+
+static WindowPtr
+xwl_xy_to_window(ScreenPtr screen, SpritePtr sprite, int x, int y)
+{
+struct xwl_screen *xwl_screen;
+struct xwl_seat *xwl_seat = NULL;
+struct xwl_window *xwl_window = NULL;
+struct xwl_touch *xwl_touch;
+int32_t client_id;
+
+xwl_screen = xwl_screen_get(screen);
+
+xorg_list_for_each_entry(xwl_seat, xwl_screen-seat_list, link) {
+if (xwl_seat-pointer-spriteInfo-sprite == sprite) {
+xwl_window = xwl_seat-focus_window;
+} else if ((client_id = lookup_sprite_touch_client_id (sprite)) != 0) {
+xwl_touch = xwl_touch_lookup_from_client_id (xwl_seat, client_id);
+
+if (xwl_touch)
+xwl_window = xwl_touch-window;
+}
+
+if (xwl_window)
+break;
}
-if (xwl_seat-focus_window) {
+if (xwl_window) {
sprite-spriteTraceGood = 2;
-sprite-spriteTrace[1] = xwl_seat-focus_window-window;
+sprite-spriteTrace[1] = xwl_window-window;
return miSpriteTrace(sprite, x, y);
}
else {
--
2.1.0
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] composite: Wrap GetSpans
On Wed, 2014-10-22 at 13:37 -0700, Keith Packard wrote: Adam Jackson a...@redhat.com writes: GetSpans should flush composition from children to parent, just like GetImage and SourceValidate. Fortunately no one is likely to have noticed, since to hit this you're already deep into failure town. In the core server code, GetSpans is only used for miCopyArea, miCopyPlane, miGetImage and miPushPixels. miPushPixels isn't relevant as it is only ever used to read from pixmaps. The others are already covered by the existing SourceValidate and GetImage wrappers. I'm not sure this is true? ProcCopyArea doesn't call SourceValidate. fbCopyArea does (by way of miDoCopy), but miCopyArea does not, in fact there's no calls to SourceValidate in mibitblt at all. So if you found yourself on the span routines and wanted to take a screenshot, GetImage would work (because composite wraps it) but CopyArea to a shm pixmap would not, the child-to-parent paint wouldn't get triggered and you'd get stale contents. If we fixed mibitblt (and fbGetImage) to call SourceValidate, then I think we could remove misprite's GetImage and GetSpans wrappers, since SourceValidate would be sufficient. And I think we could remove compGetImage too for the same reason. I guess we could argue about whether to do the SourceValidate at the top in dix or at the bottom in mi/fb/etc. Obviously this wouldn't address the other direction of rendering with IncludeInferiors to a redirected child, but it'd still be bugfix by deletion. - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xinerama: Fix access mode in GetImage's drawable lookup
Julien Cristau jcris...@debian.org writes: On Wed, Oct 8, 2014 at 17:18:32 +0200, Adam Jackson wrote: Signed-off-by: Adam Jackson a...@redhat.com --- Xext/panoramiXprocs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Julien Cristau jcris...@debian.org Merged. 942e18e..3f4edd2 master - master -- keith.pack...@intel.com pgpFvFaXcGdcT.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] dix: Always store GC client clip as a region
Adam Jackson a...@redhat.com writes:
static Bool exaFillRegionSolid(DrawablePtr pDrawable, RegionPtr pRegion,
Pixel pixel, CARD32 planemask, CARD32 alu,
- unsigned int clientClipType);
+ Bool clientClip);
Using clientClip as the name for a boolean seems likely to lead to
confusion with the usual usage of that name. Perhaps 'hasClientClip'?
void
xnestDestroyClip(GCPtr pGC)
{
-xnestDestroyClipHelper(pGC);
-
+RegionDestroy(pGC-clientClip);
Need to check for NULL before calling RegionDestroy:
@@ -276,9 +276,11 @@ xnestChangeClip(GCPtr pGC, int type, void *pValue, int
nRects)
void
xnestDestroyClip(GCPtr pGC)
{
-RegionDestroy(pGC-clientClip);
-XSetClipMask(xnestDisplay, xnestGC(pGC), None);
-pGC-clientClip = NULL;
+if (pGC-clientClip) {
+RegionDestroy(pGC-clientClip);
+XSetClipMask(xnestDisplay, xnestGC(pGC), None);
+pGC-clientClip = NULL;
+}
}
The rest of this patch has been
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpOPkOW9l6cr.pgp
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/2] render: Always store client clip as a region
Adam Jackson a...@redhat.com writes: This does have one semantic change. FixesCreateRegionFromPicture used to throw BadImplementation if you tried to create a region from a picture with no client clip. I changed that to BadMatch here since that more honestly describes what's going on. Signed-off-by: Adam Jackson a...@redhat.com Reviewed and merged. 3f4edd2..462bf87 master - master -- keith.pack...@intel.com pgpTvQ9aFNxXe.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 0/4] Finish killing VidMemInfo
Mark Kettenis mark.kette...@xs4all.nl writes: From: Adam Jackson a...@redhat.com Date: Wed, 8 Oct 2014 17:38:55 +0200 This finishes the job from: http://lists.freedesktop.org/archives/xorg-devel/2014-July/043343.html OpenBSD retains its special case for privsep setup, but otherwise this is the same as before. Please give me a chance to properly review and test this. Was travelling last week. I'd love to get this merged; have you had a chance to review this yet? -- keith.pack...@intel.com pgpP0NviJbCeq.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] xwin engine removal
Adam Jackson a...@nwnk.net writes: Adam Jackson (2): xwin: Remove native GDI engine (v2) xwin: Remove primary DirectDraw engine Merged. 462bf87..de55aaf master - master -- keith.pack...@intel.com pgp0o8Vz6Bees.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] mi: Mark the span blit routines as _X_COLD
Adam Jackson a...@redhat.com writes: On gcc, __attribute__((cold)) means: - consider calls to the function to be unlikely for branch prediction - optimize the function for size - emit the function in a dedicated cold text section It's not worth deleting these routines even though there are no longer in-tree consumers, but we can at least keep them out of i$ at runtime. Signed-off-by: Adam Jackson a...@redhat.com Reviewed and merged. de55aaf..cffd4e4 master - master -- keith.pack...@intel.com pgpmgkMHy9zGm.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] If fork fails in System(), don't fallthrough to exec()
Alan Coopersmith alan.coopersm...@oracle.com writes: Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Both of these have been merged. cffd4e4..16a32c5 master - master -- keith.pack...@intel.com pgpwf4BC9Zb_z.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Crash in X server [with Patch]
Hello, (I am not subscrided) it looks like 6e50bfa706cd3ab884c933bf1f17c221a6208aa4 in xserver is faulty. The X server used to crash every couple of hours here, with backtraces as follows (some other messages included for context): [54.054] (II) RADEON(0): Modeline 1280x1024x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [54.054] (II) RADEON(0): Modeline 1440x900x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz e) [54.054] (II) RADEON(0): Modeline 1600x1200x0.0 162.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (75.0 kHz e) [54.054] (II) RADEON(0): Modeline 1680x1050x0.0 119.00 1680 1728 1760 1840 1050 1053 1059 1080 +hsync -vsync (64.7 kHz e) [54.054] (II) RADEON(0): Modeline 1920x1080x60.0 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -hsync +vsync (67.1 kHz e) [81.990] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 4758 target_msc 4759 [ 265.465] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 15748 target_msc 15749 [ 425.104] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 25311 target_msc 25312 [ 425.120] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 25311 target_msc 25312 [ 761.224] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 45446 target_msc 45447 [ 972.308] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 58091 target_msc 58092 [ 989.809] (EE) [ 989.809] (EE) Backtrace: [ 989.813] (EE) 0: /opt/xorg/bin/Xorg (OsSigHandler+0x29) [0x594149] [ 989.815] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (__restore_rt+0x0) [0x7f4df0db7c8f] [ 989.816] (EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (strerror_l+0x6a0) [0x7f4df0a7c080] [ 989.821] (EE) 3: /opt/xorg/lib/dri/radeonsi_dri.so (memcpy_texture.isra.1+0x166) [0x7f4deb94fcc6] [ 989.825] (EE) 4: /opt/xorg/lib/dri/radeonsi_dri.so (_mesa_texstore+0x457) [0x7f4deb950927] [ 989.830] (EE) 5: /opt/xorg/lib/dri/radeonsi_dri.so (store_texsubimage+0x1ba) [0x7f4deb9514ea] [ 989.835] (EE) 6: /opt/xorg/lib/dri/radeonsi_dri.so (st_TexSubImage+0x10f) [0x7f4deb9a7b5f] [ 989.841] (EE) 7: /opt/xorg/lib/dri/radeonsi_dri.so (texsubimage+0x477) [0x7f4deb940817] [ 989.847] (EE) 8: /opt/xorg/lib/dri/radeonsi_dri.so (_mesa_TexSubImage2D+0x3f) [0x7f4deb9447ff] [ 989.853] (EE) 9: /opt/xorg/lib/xorg/modules/libglamoregl.so (__glamor_upload_pixmap_to_texture+0x1de) [0x7f4def40894e] [ 989.855] (EE) 10: /opt/xorg/lib/xorg/modules/libglamoregl.so (_glamor_upload_bits_to_pixmap_texture+0x2b9) [0x7f4def408e49] [ 989.857] (EE) 11: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_upload_sub_pixmap_to_texture+0x4c9) [0x7f4def409f79] [ 989.858] (EE) 12: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_upload_pixmap_to_texture+0x63) [0x7f4def40ad13] [ 989.860] (EE) 13: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_composite_choose_shader+0xfa4) [0x7f4def3fb724] [ 989.862] (EE) 14: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_composite_with_shader+0xce) [0x7f4def3fb9be] [ 989.864] (EE) 15: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_composite_clipped_region+0x46c) [0x7f4def3fcaac] [ 989.867] (EE) 16: /opt/xorg/lib/xorg/modules/libglamoregl.so (_glamor_composite+0x7ac) [0x7f4def3fd7ac] [ 989.869] (EE) 17: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_composite+0x3b) [0x7f4def3fdcab] [ 989.870] (EE) 18: /opt/xorg/bin/Xorg (damageComposite+0x141) [0x516d51] [ 989.872] (EE) 19: /opt/xorg/lib/xorg/modules/libglamoregl.so (glamor_trapezoids+0x2d6) [0x7f4def4069d6] [ 989.873] (EE) 20: /opt/xorg/bin/Xorg (ProcRenderTrapezoids+0x16c) [0x50d6cc] [ 989.873] (EE) 21: /opt/xorg/bin/Xorg (Dispatch+0x277) [0x438167] [ 989.873] (EE) 22: /opt/xorg/bin/Xorg (dix_main+0x3db) [0x43c30b] [ 989.876] (EE) 23: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7f4df0a04ec5] [ 989.876] (EE) 24: /opt/xorg/bin/Xorg (_start+0x29) [0x42679e] [ 989.878] (EE) 25: ? (?+0x29) [0x29] [ 989.879] (EE) [ 989.879] (EE) Segmentation fault at address 0x7f4de1950010 [ 989.879] (EE) Fatal server error: [ 989.879] (EE) Caught signal 11 (Segmentation fault). Server aborting The proposed fix is: commit bbcc084afc1396d3df42516baafea5839c95a488 Author: Andreas Hartmetz ahartm...@gmail.com Date: Sat Oct 4 18:13:04 2014 +0200 glamor: Don't free memory we are going to use. glamor_color_convert_to_bits() returns its second argument on success, NULL on error, and need_free_bits already makes sure that bits aliasing converted_bits is freed in the success case. Looks like the memory leak that was supposed to be fixed in 6e50bfa706cd3ab884c933bf1f17c221a6208aa4 only occurred in the error
Re: Crash in X server [with Patch]
On 24.10.2014 07:09, Andreas Hartmetz wrote:
commit bbcc084afc1396d3df42516baafea5839c95a488
Author: Andreas Hartmetz ahartm...@gmail.com
Date: Sat Oct 4 18:13:04 2014 +0200
glamor: Don't free memory we are going to use.
glamor_color_convert_to_bits() returns its second argument on
success, NULL on error, and need_free_bits already makes sure that
bits aliasing converted_bits is freed in the success case.
Looks like the memory leak that was supposed to be fixed in
6e50bfa706cd3ab884c933bf1f17c221a6208aa4 only occurred in the error
case.
diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
index 355fe4b..7c9bf26 100644
--- a/glamor/glamor_pixmap.c
+++ b/glamor/glamor_pixmap.c
@@ -774,8 +774,8 @@ _glamor_upload_bits_to_pixmap_texture(PixmapPtr
pixmap, GLenum format,
return FALSE;
bits = glamor_color_convert_to_bits(bits, converted_bits, w, h,
stride, no_alpha, revert,
swap_rb);
-free(converted_bits);
if (bits == NULL) {
+free(converted_bits);
ErrorF(Failed to convert pixmap no_alpha %d,
revert mode %d, swap mode %d\n, no_alpha, revert,
swap_rb);
return FALSE;
I've already, a week or two ago, sent this to Michel a who reviewed it
(no idea how to forward that, guess I'll need another review from
whoever volunteers) and OK'd it.
You could have just submitted the patch with my
Reviewed-by: Michel Dänzer michel.daen...@amd.com
to this list and to Keith Packard (Cc'd, though that probably won't be
visible in my post as distributed by the list), as I suggested. :)
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] composite: Wrap GetSpans
Adam Jackson a...@redhat.com writes: I'm not sure this is true? ProcCopyArea doesn't call SourceValidate. fbCopyArea does (by way of miDoCopy), but miCopyArea does not, in fact there's no calls to SourceValidate in mibitblt at all. Yeah, I completely missed that. So if you found yourself on the span routines and wanted to take a screenshot, GetImage would work (because composite wraps it) but CopyArea to a shm pixmap would not, the child-to-parent paint wouldn't get triggered and you'd get stale contents. If we fixed mibitblt (and fbGetImage) to call SourceValidate, then I think we could remove misprite's GetImage and GetSpans wrappers, since SourceValidate would be sufficient. And I think we could remove compGetImage too for the same reason. I guess we could argue about whether to do the SourceValidate at the top in dix or at the bottom in mi/fb/etc. Hrm. Doing it at the DIX level would rather change how software cursors work; right now, all rendering hits the software cursor pull-down code, even stuff which doesn't go directly through the DIX level. Obviously this wouldn't address the other direction of rendering with IncludeInferiors to a redirected child, but it'd still be bugfix by deletion. At this point, it seems easiest to just take your GetSpans patch as a pure bugfix and consider whether to use SourceValidate in the future, and whether to push that up to DIX or leave it down at the bottom of the rendering stack... -- keith.pack...@intel.com pgpnBIGvjaJut.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[Bug 85385] New: corrupt desktop - at and after login
https://bugs.freedesktop.org/show_bug.cgi?id=85385 Bug ID: 85385 Summary: corrupt desktop - at and after login Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: critical Priority: medium Component: Driver/Radeon Assignee: xorg-driver-ati@lists.x.org Reporter: rbell...@pteradigm.com QA Contact: xorg-t...@lists.x.org Created attachment 108324 -- https://bugs.freedesktop.org/attachment.cgi?id=108324action=edit gdm journal When the desktop environment starts up, two things can happen: 1. Before the login prompt, I get a corrupt desktop 2. After a successful login, I get a corrupt desktop In both cases, the corruption looks almost identical, so I'm assuming the problem is just different symptoms of the same problem, whether it's configuration or a bug. -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 85385] corrupt desktop - at and after login
https://bugs.freedesktop.org/show_bug.cgi?id=85385 --- Comment #1 from G. Richard Bellamy rbell...@pteradigm.com --- Created attachment 108325 -- https://bugs.freedesktop.org/attachment.cgi?id=108325action=edit Picture of what the screens look like -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 85385] corrupt desktop - at and after login
https://bugs.freedesktop.org/show_bug.cgi?id=85385 G. Richard Bellamy rbell...@pteradigm.com changed: What|Removed |Added Attachment #108325|text/plain |image/jpeg mime type|| -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 85385] corrupt desktop - at and after login
https://bugs.freedesktop.org/show_bug.cgi?id=85385 --- Comment #2 from G. Richard Bellamy rbell...@pteradigm.com --- From another shell, when stopping and then restarting gdm: -- Oct 22 18:04:40 eanna kernel: radeon :42:00.0: Saved 87 dwords of commands on ring 0. Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GPU softreset: 0x0008 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS = 0xA0003828 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS_SE0 = 0x0007 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS_SE1 = 0x0007 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: SRBM_STATUS = 0x20C0 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: SRBM_STATUS2 = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008674_CP_STALLED_STAT1 = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008678_CP_STALLED_STAT2 = 0x00010100 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_00867C_CP_BUSY_STAT = 0x00020180 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008680_CP_STAT = 0x80038042 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_SOFT_RESET=0x4001 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: SRBM_SOFT_RESET=0x0100 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS = 0x3828 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS_SE0 = 0x0007 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GRBM_STATUS_SE1 = 0x0007 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: SRBM_STATUS = 0x20C0 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: SRBM_STATUS2 = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008674_CP_STALLED_STAT1 = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008678_CP_STALLED_STAT2 = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_00867C_CP_BUSY_STAT = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_008680_CP_STAT = 0x Oct 22 18:04:40 eanna kernel: radeon :42:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: GPU reset succeeded, trying to resume Oct 22 18:04:40 eanna kernel: [drm] PCIE gen 2 link speeds already enabled Oct 22 18:04:40 eanna kernel: [drm] PCIE GART of 1024M enabled (table at 0x0025D000). Oct 22 18:04:40 eanna kernel: radeon :42:00.0: WB enabled Oct 22 18:04:40 eanna kernel: radeon :42:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x88100e3e7c00 Oct 22 18:04:40 eanna kernel: radeon :42:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x88100e3e7c0c Oct 22 18:04:40 eanna kernel: radeon :42:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc90016b1c418 Oct 22 18:04:40 eanna kernel: [drm:r600_ring_test] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Oct 22 18:04:40 eanna kernel: [drm:evergreen_resume] *ERROR* evergreen startup failed on resume -- You are receiving this mail because: You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
