[ANNOUNCE] xf86-video-qxl 0.0.17
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Version 0.0.17 of the QXL driver is available now. Soren Alon Levy (17): xspice: add missing --tls-port default README.xspice: use consistent and vnc default port spiceqxl.xorg.conf.example: typo and order fixes xspice: make --cgdb non magical, use XSPICE_ENABLE_GDB rename xspice Xspice configure.ac: support autoconf 2.63 build fixes: sched_yield and missing declaration qxl-driver: call vgaHWSetStdFuncs explicitly examples/spiceqxl.xorg.conf.example: fix in vm usage. xspice: remove duplicate declaration (fixes warning) Enable surface and caching option defaults for Xspice qxl_image: cleanup qxl_image_create xf86PciInfo.h is deprecated and unused, drop it introduce qxl_option_helpers.[ch] xspice_keyboard_proc: fix arrow keys replace lookup3 with MurmurHash3 missed when added qxl_option_helpers.c Gerd Hoffmann (1): support _ASYNC io calls and interrupt handling (busy wait) Søren Sandmann (6): Translate the access region according to the drawable offset. Use new 8BIT_A format for 8 bit pixmaps. Don't translate newly generated paccess region In qxl_check_copy() accept pixmaps that don't have surfaces Move check for zero width/height surfaces to qxl_surface_create() Don't leak the surface when we run out of video memory. Søren Sandmann Pedersen (19): Ignore devices classes when matching PCI devices Only save the VGA fonts for the primary device. Revert Use new 8BIT_A format for 8 bit pixmaps. Transmit images in smaller chunks If qxl_pre_init() is called without a confScreen, just return FALSE. Reset non-primary device out of CloseScreen(). Fix mis-merge Guard access to pci with #ifndef XPSICE Track damage for PolyLine fallbacks. Use u64_to_pointer() instead of a cast to void * Add support for parsing various options Return NULL from qxl_surface_create() when surfaces are disabled Enable caching of images based on the configuration options Enable surface and caching options for XSpice too options: Turn surfaces and caching on by default qxl_surface.c: Remove #if 0'd debug spew In qxl_prepare_access(), don't modify the width/height of the pixmap Add qxl_option_helper.h to Makefile.am Version bump to 0.0.17 git tag: xf86-video-qxl-0.0.17 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.0.17.tar.bz2 MD5: c0ee45ce06654b9f2e6ddac478d5fbd6 xf86-video-qxl-0.0.17.tar.bz2 SHA1: b4efa1cde649c0f3b362c9872041397a973c7526 xf86-video-qxl-0.0.17.tar.bz2 SHA256: 193c2bb4889de39f7b0071990adaae1753b45e542f68d76cc0d55a7299b49f82 xf86-video-qxl-0.0.17.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-qxl-0.0.17.tar.gz MD5: 1d91021d00eed2399ca67e6f187ed7ff xf86-video-qxl-0.0.17.tar.gz SHA1: 2ecb1d0741902f23e270be8cbb69415aa95fea02 xf86-video-qxl-0.0.17.tar.gz SHA256: 8bd462a1e800e3a7e36fa75f900904e77b0433f4ac9367cd447ce7f7d1c62cd4 xf86-video-qxl-0.0.17.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk9iL5oACgkQmxfmIW/3wajDBQCfZVz3mUPbIBZXC38s+Pll4LFw DnQAoJDyhu4MhjlYusa+YNyFPSX60jSB =NTFo -END PGP SIGNATURE- ___ 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: arch...@mail-archive.com
Re: x forwarding? Fixed?
gene heskett wrote: In my experience, enabling debugging on the server side (via the LogLevel directive in sshd_config) tends to be more useful than the debug information produced by the client. In this case 'server' I assume being the machine I am targeting, aka 'lathe'? Yes; the machine running the sshd daemon. The ssh client can only tell you what the ssh server tells it, and it's in the nature of the secure shell protocol for the server not to tell the client too much. It may tell it if something failed, but probably not exactly how or why it failed. -- Glynn Clements gl...@gclements.plus.com ___ 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: arch...@mail-archive.com
Re: x forwarding? Fixed?
On Friday, March 16, 2012 12:29:58 AM Glynn Clements did opine: gene heskett wrote: In my experience, enabling debugging on the server side (via the LogLevel directive in sshd_config) tends to be more useful than the debug information produced by the client. In this case 'server' I assume being the machine I am targeting, aka 'lathe'? Yes; the machine running the sshd daemon. I _think_ its running but I will add that debug level to the config file the next time I boot it. I need to get the motor controllers power supplies assembled next. This box will be running a cnc'd lathe when its all assembled. The ssh client can only tell you what the ssh server tells it, and it's in the nature of the secure shell protocol for the server not to tell the client too much. It may tell it if something failed, but probably not exactly how or why it failed. I can understand that reticence. I was out in the garage a bit ago, updated that machine then shut it off, intending to get some beauty sleep. Alas, I've fooled around and failed, not that it would do me much good with all the calendars I've thrown away. ;-) Thanks Glynn. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene Don't vote -- it only encourages them! ___ 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: arch...@mail-archive.com
Re: [PATCH] dix: put warning in for scroll increments of 0
#part sign=pgpmime On Thu, 15 Mar 2012 13:46:56 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: If the increment is 0 but this is a scroll axis, it's definitely a bug. Nonetheless, it has happened, so put a warning in and a return statement that we avoid the infinite loop and hopefully be able to reproduce later. (an ugly hack, but better than spinning forever) Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com ___ 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
vmware driver freeing non malloced object
Just packaged xorg-x11-drv-vmware-12.0.1 and got this in build logs /bin/sh ../libtool --silent --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -fvisibility=hidden -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm -I../src -I../saa -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -c -o libvmwgfx_la-vmwgfx_xa_surface.lo `test -f 'vmwgfx_xa_surface.c' || echo './'`vmwgfx_xa_surface.c In file included from /usr/include/xorg/region.h:51:0, from /usr/include/xorg/mi.h:51, from vmwgfx_saa.c:29: In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1154:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1158:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] CCLD libvmwgfx.la Dave. ___ 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 v2 6/9] Xext: store the bracket values for idle counters in the private
A small detail:
On 3/14/12, Peter Hutterer peter.hutte...@who-t.net wrote:
static void
IdleTimeWakeupHandler (pointer pCounter, int rc, pointer LastSelectMask)
{
-SyncCounter *counter = IdleTimeCounter;
+SyncCounter *counter = pCounter;
...
@@ -2814,7 +2817,7 @@ IdleTimeWakeupHandler (pointer pCounter, int rc,
pointer LastSelectMask)
if ((greater XSyncValueGreaterOrEqual (idle, *greater)) ||
(less XSyncValueLessOrEqual (idle, *less)))
{
- SyncChangeCounter (counter, idle);
+ SyncChangeCounter ((SyncCounter*)pCounter, idle);
}
}
You have a properly-typed counter in scope now, so you can drop this hunk.
Jamey
___
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 evdev] Fix inverted horizontal scroll (#46205)
On 03/14/2012 10:56 PM, Peter Hutterer wrote: REL_HWHEEL has a positive increment, not a negative one like REL_WHEEL. X.Org Bug 46205 http://bugs.freedesktop.org/show_bug.cgi?id=46205 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net I have seen this bug too, but haven't had a chance to fix it. This looks correct. Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ 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 v2 9/9] Xext: Add per-device SyncCounters
For the series v2: Looks good!
Reviewed-by: Jamey Sharp ja...@minilop.net
Although I'd suggest dropping the unnecessary cast I pointed out in patch 6.
Jamey
On 3/14/12, Peter Hutterer peter.hutte...@who-t.net wrote:
Previously, we only had one idle alarm that was triggered for all devices,
whenever the user used any device, came back from suspend, etc.
Add system SyncCounters for each device (named DEVICEIDLETIME x, with x
being the device id) that trigger on that device only. This allows for
enabling/disabling devices based on interaction with other devices.
Popular use-case: disable the touchpad when the keyboard just above the
touchpad stops being idle.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
Reviewed-by: Jeremy Huddleston jerem...@apple.com
---
Changes to v1:
- adapt to SysCounterGetPrivate
- adapt to SysCounterList being a linked list
Xext/sync.c| 48 +++-
Xext/syncsrv.h |3 +++
dix/devices.c |8
include/inputstr.h |2 ++
4 files changed, 56 insertions(+), 5 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 5479381..c2f6573 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -70,6 +70,7 @@ PERFORMANCE OF THIS SOFTWARE.
#include syncsrv.h
#include syncsdk.h
#include protocol-versions.h
+#include inputstr.h
#include stdio.h
#if !defined(WIN32)
@@ -2715,12 +2716,22 @@ SyncInitServerTime(void)
typedef struct {
XSyncValue *value_less;
XSyncValue *value_greater;
+int deviceid;
} IdleCounterPriv;
static void
IdleTimeQueryValue (pointer pCounter, CARD64 *pValue_return)
{
-CARD32 idle = GetTimeInMillis() -
lastDeviceEventTime[XIAllDevices].milliseconds;
+int deviceid;
+CARD32 idle;
+
+if (pCounter) {
+SyncCounter *counter = pCounter;
+IdleCounterPriv *priv = SysCounterGetPrivate(counter);
+deviceid = priv-deviceid;
+} else
+deviceid = XIAllDevices;
+idle = GetTimeInMillis() - lastDeviceEventTime[deviceid].milliseconds;
XSyncIntsToValue (pValue_return, idle, 0);
}
@@ -2813,7 +2824,7 @@ IdleTimeWakeupHandler (pointer pCounter, int rc,
pointer LastSelectMask)
if (!less !greater)
return;
-IdleTimeQueryValue (NULL, idle);
+IdleTimeQueryValue (pCounter, idle);
if ((greater XSyncValueGreaterOrEqual (idle, *greater)) ||
(less XSyncValueLessOrEqual (idle, *less)))
@@ -2849,8 +2860,8 @@ IdleTimeBracketValues (pointer pCounter, CARD64
*pbracket_less,
priv-value_less= pbracket_less;
}
-static void
-SyncInitIdleTime (void)
+static SyncCounter*
+init_system_idle_counter(const char *name, int deviceid)
{
CARD64 resolution;
XSyncValue idle;
@@ -2860,12 +2871,39 @@ SyncInitIdleTime (void)
IdleTimeQueryValue (NULL, idle);
XSyncIntToValue (resolution, 4);
-idle_time_counter = SyncCreateSystemCounter(IDLETIME, idle,
resolution,
+idle_time_counter = SyncCreateSystemCounter(name, idle, resolution,
XSyncCounterUnrestricted,
IdleTimeQueryValue,
IdleTimeBracketValues);
+priv-deviceid = deviceid;
priv-value_less = priv-value_greater = NULL;
idle_time_counter-pSysCounterInfo-private = priv;
+
+return idle_time_counter;
+}
+
+static void
+SyncInitIdleTime (void)
+{
+init_system_idle_counter(IDLETIME, XIAllDevices);
}
+
+SyncCounter*
+SyncInitDeviceIdleTime(DeviceIntPtr dev)
+{
+char timer_name[64];
+sprintf(timer_name, DEVICEIDLETIME %d, dev-id);
+
+return init_system_idle_counter(timer_name, dev-id);
+}
+
+void SyncRemoveDeviceIdleTime(SyncCounter *counter)
+{
+/* ResetProc frees the list before devices are shutdown and try to
+ * delete their counters again */
+if (!xorg_list_is_empty(SysCounterList))
+xorg_list_del(counter-pSysCounterInfo-entry);
+}
+
diff --git a/Xext/syncsrv.h b/Xext/syncsrv.h
index 27b533c..84c7aee 100644
--- a/Xext/syncsrv.h
+++ b/Xext/syncsrv.h
@@ -139,4 +139,7 @@ extern void SyncDestroySystemCounter(
);
extern void SyncExtensionInit(void);
+
+extern SyncCounter *SyncInitDeviceIdleTime(DeviceIntPtr dev);
+extern void SyncRemoveDeviceIdleTime(SyncCounter *counter);
#endif /* _SYNCSRV_H_ */
diff --git a/dix/devices.c b/dix/devices.c
index 7478ad6..a488d41 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -87,6 +87,7 @@ SOFTWARE.
#include enterleave.h /* for EnterWindow() */
#include xserver-properties.h
#include xichangehierarchy.h /* For XISendDeviceHierarchyEvent */
+#include syncsrv.h
/** @file
* This file handles input device-related stuff.
@@ -419,9 +420,13 @@ EnableDevice(DeviceIntPtr dev, BOOL sendevent)
RecalculateMasterButtons(dev);
+/* initialise an idle timer for this device*/
+
Re: server-1.12-branch
Hi, On 14 March 2012 04:09, Keith Packard kei...@keithp.com wrote: #part sign=pgpmime On Wed, 14 Mar 2012 01:45:47 +, Daniel Stone dan...@fooishbar.org wrote: I can definitely see the argument here. Keith, do you want me to send you an automated whole-tree changeset, followed by a series of cleanups? To be honest, I've only got Xext totally cleaned up right now, so I could send those two first and then the rest as they get done (reading 550k LoC is a fairly tough slog). Yes, something entirely automated would be best; it's easy to review, and easy to verify. And, it would let us do the same command on stable branches as well. OK, it's on people.fd.o/~daniels/xserver:coding-style now (d2949a1), plus one small fixup for a really obnoxiously-formatted block in, surprise surprise, Xinerama. Although it was pretty obnoxiously formatted to begin with, to be fair. I've changed the command a bit to add all the typedefs, which gives indent a much better idea of what's going on and stops it from adding pointless spaces after ampersands (grr). There were still a few of those as I failed to capture every single typedef in the original indent command, which can be seen in the first commit message. It's not perfect - and really, only straight-up slogging through every file is going to turn up the pathological cases - but it's as good as we're going to get for the moment. Could you please pull these and then we can fix up the fallout as we go along? Cheers, Daniel ___ 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/9] per-device idle counters
On 3/14/12 5:20 PM, Peter Hutterer wrote:
On Wed, Mar 14, 2012 at 05:11:04PM -0700, James Jones wrote:
I like the cleanups here. I prefer the SysCounterGetPrivate() helper over
the macro, but don't particularly think the need to allow
SyncNumSystemCounters to go negative by decrementing in ResetProc() is a
win for clarity.
sorry, I'm having troubles parsing this sentence. So you'd prefer leaving
SyncNumSystemCounters out decrement it automatically even after the
container array has been removed already?
or force-reset it to 0 and only decrement while the list is still present,
leaving the counter at 0? (which is what the first diff below adds)
Sorry for not being clear. I would prefer not force-resetting it to 0, aka,
leaving 1/9 out of the series. You could check SyncCounterList != NULL instead
of SyncNumSystemCounters in the 9/9. If the inconsistency needs to be fixed, I
slightly prefer Jamey's linked-list patch.
The inconsistency between the list and count would even be useful if there was
somewhere to assert/BUG_WARN that the number settles to 0. I suppose you could
add a BUG_WARN_MSG(SystemCounterList || (SyncNumSystemCounters == 0)) in
SyncCreateSystemCounter() to catch it on server generations.
Thanks,
-James
Cheers,
Peter
On 3/14/12 4:30 PM, Peter Hutterer wrote:
On Wed, Mar 14, 2012 at 09:01:13AM -0700, Jamey Sharp wrote:
This series seems like a good idea to me! I have a few review comments
though:
Patch 1 seems strange. Shouldn't the counters themselves get freed at
reset? If they are, shouldn't that lead to the number of counters
reaching 0?
you're right but the order is a tad weird. The ResetProc is called before
the counters are cleaned up, so we free the container list but the number is
still correct. Later, the number goes down to 0 when the counters are
actually freed. Technically correct, but weird. I think the diff below would
make sense to merge into patch 1/9. This way, we remove all knowledge of
system counters in the ResetProc and don't get any weird effects.
diff --git a/Xext/sync.c b/Xext/sync.c
index 6c8c564..bf47c93 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -1200,8 +1200,8 @@ FreeCounter(void *env, XID id)
SysCounterList[i] = SysCounterList[i+1];
}
}
+SyncNumSystemCounters--;
}
- SyncNumSystemCounters--;
}
free(pCounter);
return Success;
I guess the input ABI should get bumped for the patch that stores
per-device idle times. We decided to bump ABI more aggressively,
right?
correct, but I need to go through my lists to check whether I've got
anything else that bumps the ABI in the near future. If so, I prefer
bundling them with one ABI bump.
I haven't checked: is it possible to build xserver without SYNC, or to
disable it at runtime? If so, the final patch needs some conditionals,
I assume.
in configure.ac:1312, it's always defined, so no conditionals are necessary.
AC_DEFINE(XSYNC, 1, [Support XSync extension])
Here's a request you can ignore if you like: Please consider making
SYSCOUNTERPRIV a static inline instead of a macro, and removing the
cast from inside it. That'd be different from the usual idiom in the X
server, but the usual idiom is dumb. :-) I'd prefer to see all the
callers assign their pointer pCounters to an appropriately-typed
local once right at the beginning of the function, which also serves
as documentation for what type you're supposed to pass in there.
How does this one look then? I'd squash this in but it's easier to review as
a diff on top.
From cc02b58e95822a50658ef7fe13e862c3f569ee22 Mon Sep 17 00:00:00 2001
From: Peter Huttererpeter.hutte...@who-t.net
Date: Thu, 15 Mar 2012 09:27:24 +1000
Subject: [PATCH] Xext: replace the macro with a static inline function.
Signed-off-by: Peter Huttererpeter.hutte...@who-t.net
---
Xext/sync.c| 24 ++--
Xext/syncsrv.h |2 --
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index 6c8c564..5f74dab 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -115,6 +115,15 @@ static void SyncInitServerTime(void);
static void SyncInitIdleTime(void);
+static inline void*
+SysCounterGetPrivate(SyncCounter *counter)
+{
+BUG_WARN(!IsSystemCounter(counter));
+
+return counter-pSysCounterInfo ? counter-pSysCounterInfo-private :
NULL;
+}
+
+
static Bool
SyncCheckWarnIsCounter(const SyncObject* pSync, const char *warning)
{
@@ -2747,7 +2756,8 @@ IdleTimeQueryValue (pointer pCounter, CARD64
*pValue_return)
CARD32 idle;
if (pCounter) {
-IdleCounterPriv *priv = SYSCOUNTERPRIV(pCounter);
+SyncCounter *counter = pCounter;
+IdleCounterPriv *priv = SysCounterGetPrivate(counter);
deviceid = priv-deviceid;
} else
deviceid = XIAllDevices;
@@
Re: server-1.12-branch
#part sign=pgpmime On Thu, 15 Mar 2012 15:20:58 +, Daniel Stone dan...@fooishbar.org wrote: OK, it's on people.fd.o/~daniels/xserver:coding-style now (d2949a1), plus one small fixup for a really obnoxiously-formatted block in, surprise surprise, Xinerama. Although it was pretty obnoxiously formatted to begin with, to be fair. I'm testing that now; will do the asm-level compare shortly and push. I'll also post a script for doing the comparison; I should have done that before, I'm recreating that from scratch now... Thanks much for taking this adventure on. -- keith.pack...@intel.com ___ 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: vmware driver freeing non malloced object
On Thursday, March 15, 2012 10:14:25 AM Dave Airlie wrote: Just packaged xorg-x11-drv-vmware-12.0.1 and got this in build logs /bin/sh ../libtool --silent --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..-Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -Wbad-function-cast -Wformat=2 -Wold-style-definition -Wdeclaration-after-statement -fvisibility=hidden -I/usr/include/xorg -I/usr/include/pixman-1 -I/usr/include/libdrm -I../src -I../saa -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -c -o libvmwgfx_la-vmwgfx_xa_surface.lo `test -f 'vmwgfx_xa_surface.c' || echo './'`vmwgfx_xa_surface.c In file included from /usr/include/xorg/region.h:51:0, from /usr/include/xorg/mi.h:51, from vmwgfx_saa.c:29: In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1154:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] In function 'RegionUninit.isra.2', inlined from 'vmwgfx_composite_prepare' at vmwgfx_saa.c:1158:5: /usr/include/xorg/regionstr.h:143:6: warning: attempt to free a non-heap object 'RegionEmptyData' [-Wfree-nonheap-object] CCLD libvmwgfx.la Thanks Dave! I just pushed a fix for it. z ___ 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 v2] x86emu: Correctly handle 0x66 prefix for some instructions
On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover guil...@hadrons.org wrote: On Fri, 2012-03-09 at 00:02:55 +, Julian Pidancet wrote: Some instructions are not emulated correctly by x86emu when they are prefixed by the 0x66 opcode. I've identified problems in the emulation of these intructions: ret, enter, leave, iret and some forms of call. Most of the time, the problem is that these instructions should push or pop 32-bit values to/from the stack, instead of 16bit, when they are prefixed by the 0x66 special opcode. The SeaBIOS project aims to produce a complete legacy BIOS implementation as well as a VGA option ROM, entirely written in C and using the GCC compiler. In 16bit code produced by the GCC compiler, the 0x66 prefix is used almost everywhere. This patch is necessary to allow the SeaBIOS VGA option ROM to function with Xorg when using the vesa driver. v2: - Decrement BP instead of EBP in accordance with the Intel Manual - Assign EIP instead of IP when poping the return address from the stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret - When poping EFLAGS from the stack in iret in 32-bit operand size mode, apply some mask to preserve Read-only flags. Signed-off-by: Julian Pidancet julian.pidan...@gmail.com Looks good to me: Reviewed-by: Guillem Jover guil...@hadrons.org thanks, guillem Anyone interested in this ? Is there a maintainer for x86emu ? The MAINTAINERS file in xorg-docs doesn't mention anything about it. -- Julian ___ 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 v2] x86emu: Correctly handle 0x66 prefix for some instructions
On Thu, Mar 15, 2012 at 10:39 PM, Julian Pidancet julian.pidan...@gmail.com wrote: On Fri, Mar 9, 2012 at 2:08 AM, Guillem Jover guil...@hadrons.org wrote: On Fri, 2012-03-09 at 00:02:55 +, Julian Pidancet wrote: Some instructions are not emulated correctly by x86emu when they are prefixed by the 0x66 opcode. I've identified problems in the emulation of these intructions: ret, enter, leave, iret and some forms of call. Most of the time, the problem is that these instructions should push or pop 32-bit values to/from the stack, instead of 16bit, when they are prefixed by the 0x66 special opcode. The SeaBIOS project aims to produce a complete legacy BIOS implementation as well as a VGA option ROM, entirely written in C and using the GCC compiler. In 16bit code produced by the GCC compiler, the 0x66 prefix is used almost everywhere. This patch is necessary to allow the SeaBIOS VGA option ROM to function with Xorg when using the vesa driver. v2: - Decrement BP instead of EBP in accordance with the Intel Manual - Assign EIP instead of IP when poping the return address from the stack in 32-bit operand size mode in ret_far_IMM, ret_far, and iret - When poping EFLAGS from the stack in iret in 32-bit operand size mode, apply some mask to preserve Read-only flags. Signed-off-by: Julian Pidancet julian.pidan...@gmail.com Looks good to me: Reviewed-by: Guillem Jover guil...@hadrons.org thanks, guillem Anyone interested in this ? Is there a maintainer for x86emu ? The MAINTAINERS file in xorg-docs doesn't mention anything about it. CCed: Adam Jackson Adam, you seem to be the maintainer of the xorg vesa driver. I think this patch is closely related. Would you mind taking a look at it ? Thanks, -- Julian ___ 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#663953: xserver-xorg-video-radeon: when start gdm3 the screen image was crupted
On Mit, 2012-03-14 at 17:08 +0800, lhs wrote: when starting gdm3 , the screen image was crupted! Corrupted how? Xorg X server log files on system: -- -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.438.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.434.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.339.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.437.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.338.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.439.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.436.log -rw-r--r-- 1 root root 19371 Feb 12 08:35 /var/log/Xorg.435.log [...] Such a large number of log files created in a short amount of time makes me think of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650183 , which I sometimes hit even when the X server works just fine. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 26916] Current xf86-video-ati lacks size and position controls for the TV-out
https://bugs.freedesktop.org/show_bug.cgi?id=26916 --- Comment #12 from Da Fox da_...@mad.scientist.com 2012-03-15 01:48:38 PDT --- (In reply to comment #11) Created attachment 58292 [details] [review] v5: more control Ok, I finally got around to doing a quick test: - The increased accuracy for horizontal positioning seems to be working great - The vertical position and horizontal size still use the 'steps of 10', it would be great if these could be positioned more accurately too. - There seems to be some discrepancy between NTSC and PAL modes (I only tested these two): the horizontal position adjust in the PAL case wasn't able to shift the image as far left as in the NTSC case. In fact setting the value to '0' (lowest value) it was still too far to the right. - The same seemed true for the vertical size too (cannot move up the image far enough) - The horizontal size control is ineffective/not working. - Is it possible to have a vertical size control too? Final remarks: It's a bit unintuitive to have 50 as a center, as you have to do remember to subtract or add the desired offset from 50. If there is a way to make the negative values work that would also be nice. Also everytime xrandr is invoked the image on the TV set 'flickers', as if the tv needs to re-adjust to the signal or something, even if nothing was changed (e.g. invalid parameter, etc). Would it possible to a) not take an action/reinit tvout if nothing changed b) reduce the amount of 'flicker' even when something does change? Perhaps waiting for vblank or something? (I'm just throwing some ideas). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #6 from Ernst Sjöstrand ern...@gmail.com 2012-03-15 06:52:29 PDT --- That might have been an instance of https://bugs.freedesktop.org/show_bug.cgi?id=45366 But that lockup doesn't happen every time and this happens all the time, on almost every draw operation of some type in these Gnome applications. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #7 from Ernst Sjöstrand ern...@gmail.com 2012-03-15 06:53:47 PDT --- So to clarify, no messages of any kind are shown in dmesg och Xorg-log for this graphics corruption. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47266] Graphics corruption in Gnome windows (Radeon/Barts)
https://bugs.freedesktop.org/show_bug.cgi?id=47266 --- Comment #8 from Ernst Sjöstrand ern...@gmail.com 2012-03-15 06:54:38 PDT --- I have the following in my rc.local: echo profile /sys/class/drm/card0/device/power_method echo auto /sys/class/drm/card0/device/power_profile -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47363] New: Connecting DVI-0 Display-Port-0 and HDMI-0 only 2 of those can be enabled once
https://bugs.freedesktop.org/show_bug.cgi?id=47363 Bug #: 47363 Summary: Connecting DVI-0 Display-Port-0 and HDMI-0 only 2 of those can be enabled once Classification: Unclassified Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/Radeon AssignedTo: xorg-driver-ati@lists.x.org ReportedBy: tomas.chva...@gmail.com QAContact: xorg-t...@lists.x.org Created attachment 58516 -- https://bugs.freedesktop.org/attachment.cgi?id=58516 Xorg.0.log As above I have 3 screens, each one attached to one connection. While trying to set up this error is shown on dmesg and I can use only 2 screens at once. I would preffer if I could set up all three monitors at once. In dmesg there is only this error: [drm:radeon_dp_get_link_status] *ERROR* displayport link status failed [drm:radeon_dp_get_link_status] *ERROR* displayport link status failed -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 47363] Connecting DVI-0 Display-Port-0 and HDMI-0 only 2 of those can be enabled once
https://bugs.freedesktop.org/show_bug.cgi?id=47363 Alex Deucher ag...@yahoo.com changed: What|Removed |Added AssignedTo|xorg-driver-ati@lists.x.org |dri-devel@lists.freedesktop ||.org QAContact|xorg-t...@lists.x.org | Product|xorg|DRI Component|Driver/Radeon |DRM/Radeon --- Comment #1 from Alex Deucher ag...@yahoo.com 2012-03-15 08:34:30 PDT --- Please attach your dmesg output as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 41838] Kernel Crash/Hanging system in connection between WebKit and Gnome-Shell
https://bugs.freedesktop.org/show_bug.cgi?id=41838 Peter Weber peter.we...@ttyhoney.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #44 from Peter Weber peter.we...@ttyhoney.com 2012-03-15 12:58:49 PDT --- The good news: mesa-8.0 is stable The better news: mesa-8.0.1-2 is stable in archlinux repositories The best news: it fixed officially! The sad news: still don't know what it finally fixed ;-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #23 from d4ddi0 stillcompil...@gmail.com 2012-03-15 19:33:58 PDT --- (In reply to comment #20) (In reply to comment #18) I have not yet applied Alex's patch, [...] Have you been able to test it in the meantime? It doesn't seem very likely it'll help, but... I did finallly try the gart alignment patch (required a minor tweak, gart.table.ram.ptr changed to gart.ptr) No change and no line in dmesg. BTW, I am a C programmer... If I knew where to start, I'd love to work on this problem from a code angle. I've looked at the code somewhat, but even in the code specific to my driver there is a lot of code in different places. See e.g. rs690_mc_init() in drivers/gpu/drm/radeon/rs690.c . Thanks! I am poking around in drm/radeon. I wonder if it is possible to step through loading radeon.ko in gdb... There is no serial port on this puppy (In reply to comment #21) Might also be related to bug 37679 (interrupt problems). Can you try a similar patch to the ones on that bug? The quirks in bug 37679 seem to just force msi. Thesymtos do not seem to apply. interrup count steadily rises with glxgears. I also booted with radeon.msi=1 (which has the same effect). No difference other than being assigned a different irq (In reply to comment #22) I have a packard bell dot m/a (radeon x1270) and have the issue described in this bug. My setup: * kernel 3.2 * libdrm 2.4.30 * mesa 7.11.2 I replaced the bios with a modded one that allow tweaking of video ram type. I tried two settings: uma only and uma+sideport. * UMA (256M) * No graphic corruption * No laggy window movement * glxgear fps ~= 360 * UMA+sideport (256M+64M) * Massive graphic corruption * Laggy window movement * glxgears fps ~= 200 A diff between dmesg output: $ diff dmesg.uma dmesg.uma+sideport 9c9 [drm] Detected VRAM RAM=256M, BAR=256M --- [drm] Detected VRAM RAM=384M, BAR=256M 11c11 [drm] radeon: 256M of VRAM memory ready --- [drm] radeon: 384M of VRAM memory ready 15c15 [drm] PCIE GART of 512M enabled (table at 0x6C18). --- [drm] PCIE GART of 512M enabled (table at 0x6B80). 31a32 [drm] radeon: power management initialized Hope it can help. I can make more test if needed. That 384 number seems like the most likely suspect. I see indications several places that theres only 64M of sideport VRAM, but 384 == 128 + 256 I'm not sure where that specific piece of data (the 128M of internal vram) is coming from, or whether it can be fixed by poking 64 * 1024 * 1024 into some register... I tried arbitrarily setting rdev-mc.real_vram_size to 320M as soon as it was set, but that had no effect -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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
