X server 1.6_beta1 pending pixman
Søren asked me to move the render matrix operations into pixman, which makes perfect sense. However, that means that X server 1.6 will depend on a pixman with those functions, so I can't release beta1 until pixman is ready to ship with that stuff as well. I don't mind shipping an X server beta that depends on pixman beta bits, but I don't want to ship an X server that requires unreviewed code. So, we'll see if we can't get a bit of pixman review and perhaps a pixman release done tomorrow so that the X server beta can head out. -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Additional NULL (??) layout group with evdev+hal
On Tue, Nov 25, 2008 at 11:11:29AM +0900, Thomas Fritzsche wrote: > Hello Peter, > That's oddI have installed latest Ubuntu package for xorg-server > and this is 1.5.2. > http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg-server/xorg-server_1.5.2-2ubuntu3/changelog 2:1.5.1-1ubuntu3 should have the patch and unless it disappeared since, it should still be in there. > Is there any more information I can provide you except of the earlier > attached output from "xkbcomp -xkb :0 -" ? Please try to find the simplest reproduceable test-case. Ideally, this would be a plain X server with nothing but xterm (or even just the X server itself). Other than that, it's pretty much down to looking at the code. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Frame buffer Changed Event.
Hi Adam, Does damage extension have the api to notify if the framebuffer has already been updated with the data? Need something to notify me if buffer has already been updated and ready for display so I can send the data to the actual physical display device. Thanks and best regards, Andy - Original Message - From: Leandro Galvez To: xorg@lists.freedesktop.org Sent: Friday, November 21, 2008 5:43 PM Subject: Frame buffer Changed Event. Hi All, I am using Xorg on top of Linux virtual frame buffer. What type of event or hook should I use to catch events after any part of the frame buffer has been updated? I would like to catch events that would trigger right after the frame data buffer has changed so I could feed the contents of the vfb to an actual device that can display it. I would like to catch the events globally and not just in specific applications. Thanks and best regards, Andy -- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Additional NULL (??) layout group with evdev+hal
Hello Peter, That's oddI have installed latest Ubuntu package for xorg-server and this is 1.5.2. http://changelogs.ubuntu.com/changelogs/pool/main/x/xorg-server/xorg-server_1.5.2-2ubuntu3/changelog I'll try to double check the source package when I have access to my linux box tonight, but currently it seems something is now working even with these patches. Is there any more information I can provide you except of the earlier attached output from "xkbcomp -xkb :0 -" ? Thanks so much for your help. Cheers, Thomas On Tue, Nov 25, 2008 at 7:03 AM, Peter Hutterer <[EMAIL PROTECTED]> wrote: > > On Mon, Nov 24, 2008 at 11:19:33PM +0900, Thomas Fritzsche wrote: > > > > Somehow this first version is broken creating the 3rd layout group. > > I guess I need to put these 2 patches in my xserver that you created for: > > http://bugs.freedesktop.org/show_bug.cgi?id=14373 > > Or is this other case? > > yeah, but both of them should be in 1.5.2. Can you please check whether you > have that code, or whether it's something else gone wrong? > > Cheers, > Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PULL] input fixes for server-1.5-branch
Ajax,
Please pull a few input fixes for server-1.5-branch:
git pull git://people.freedesktop.org/~whot/xserver.git server-1.5-branch
Alan Coopersmith (1):
Non-Linux OS'es should default to kbd driver, not now-dead keyboard driver
Peter Hutterer (3):
dix: extra sanity-checks against potential NULL-dereferences.
xfree86: AllowEmptyInput is true by default - update the xf86Info
defaults.
xfree86: without CONFIG_HAL, Auto{Add|Enable}Devices and AEI is false.
Rémi Cardona (1):
xfree86: don't reset Auto(Add|Enable)Devices, use defaults from
xf86Globals
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multiple Servers (Was RE: XGetImage returns junk with Xorg/dummy_drv/VTs)
McDonald, Michael-p7438c wrote: > I still feel that Xorg+dummy_drv should return a valid image but we > can agree to disagree on that. Actually, I agree with you on that point (and said so a few messages back). Where we can agree to disagree is on the topic of weather GetImage(root_window) is a useful operation in general. > So, my problem is I need at least three X servers running on a single > machine. Each X server needs to support hardware accelerated OpenGL and > XVideo-MotionCompensation. Our underlying hardware is Intel GM45 based. > The three servers need to be completely independent of each other for > security reasons. None of the three will have access to any real > displays. We'll use access to the framebuffers (XGetImage would have > been nice but we're willing to modify the driver if necessary) to > composite the three outputs into a single, combined out. > Any suggestions on a better approach? If performance matters (and if you need XvMC, I'm guessing it does), you may be better off biting the bullet and writing a stronger set of Xace hooks to get the security you need from a single server. You won't get performance with GetImage. Other than that, perhaps you can use the Composite extension to redirect drawing into pixmaps, which (unlike windows) can be reliably retrieved with GetImage. xcompmgr (and/or compiz) might be an interesting base to start from. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Multiple Servers (Was RE: XGetImage returns junk with Xorg/dummy_drv/VTs)
> -Original Message- > From: Peter Harris [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 3:02 PM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > I forgot to remind you about Xsecurity/Xace. In a properly secured > setup, Xsecurity/Xace isn't a problem in our case as neither is sufficiently secure for our needs. So they'll be disabled. I still feel that Xorg+dummy_drv should return a valid image but we can agree to disagree on that. So, my problem is I need at least three X servers running on a single machine. Each X server needs to support hardware accelerated OpenGL and XVideo-MotionCompensation. Our underlying hardware is Intel GM45 based. The three servers need to be completely independent of each other for security reasons. None of the three will have access to any real displays. We'll use access to the framebuffers (XGetImage would have been nice but we're willing to modify the driver if necessary) to composite the three outputs into a single, combined out. Xvfb almost meets our needs for the three X servers except it doesn't support XVideo-MotionCompensation. Any suggestions on a better approach? Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [synaptics] [patch] touchpad output noise that confuse driver
On Sun, Nov 23, 2008 at 08:46:14PM +0100, Batchty wrote: > Hello, I have a Dell Inspiron 1520 with a Synaptics touchpad. This touchpad > for > a unknown reason loves to send event like these after every finger release : > > time xy z f w l r u d m multi gl gm gr gdx gdy >1.563 3224 1625 57 1 5 0 0 0 0 0 0 0 0 0 0 >1.574 3251 1632 30 1 5 0 0 0 0 0 0 0 0 0 0 >1.584 3292 1673 10 1 5 0 0 0 0 0 0 0 0 0 0 >1.594 1 5855 3 2 5 0 0 0 0 0 0 0 0 0 0 >1.634 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 >1.746 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 >1.897 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > > Most of the time these events are ignored by the driver. but sometimes > it confuse two-finger scrolling and tap detection. > > For example, in this log, the first tap is recognized, the second isn't : > > time xy z f w l r u d m multi gl gm gr gdx gdy > 11.597 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > 11.678 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 > 11.688 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > 11.709 3862 2406 8 1 5 0 0 0 0 0 0 0 0 0 0 > 11.719 3851 2464 67 1 5 0 0 0 0 0 0 0 0 0 0 > 11.729 3849 2407 35 1 4 0 0 0 0 0 0 0 0 0 0 > 11.739 3858 2578 5 1 9 0 0 0 0 0 0 0 0 0 0 > 11.749 3858 2578 0 0 0 0 0 0 0 0 0 0 0 0 0 > 11.850 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > 11.860 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 > 12.073 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > 12.083 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 > 12.347 1 5855 4 2 5 0 0 0 0 0 0 0 0 0 0 > 12.357 3844 2381 56 1 4 0 0 0 0 0 0 0 0 0 0 > 12.377 3848 2361 32 1 4 0 0 0 0 0 0 0 0 0 0 > 12.388 1 5855 3 2 5 0 0 0 0 0 0 0 0 0 0 > 12.398 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > 12.408 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 > 12.428 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > > The problem with the second tap is that the driver check if the movement from > (3848,2361) to (1,5855) is over TapMaxMove before it checks for a finger > release. > So the driver considers it as a (short) finger move. > The first patch add the condition ''the finger is still present'' to > the 'move' condition. > > The other problem is with double-finger scrolling. In this log, the driver > send hundred of scroll-down events : > >2.457 3220 2025 75 2 5 0 0 0 0 0 0 0 0 0 0 >2.467 3244 1933 75 2 5 0 0 0 0 0 0 0 0 0 0 >2.477 3275 1864 75 2 5 0 0 0 0 0 0 0 0 0 0 >2.488 3329 1835 21 2 5 0 0 0 0 0 0 0 0 0 0 >2.508 3461 1803 7 2 5 0 0 0 0 0 0 0 0 0 0 >2.519 1 5855 2 2 5 0 0 0 0 0 0 0 0 0 0 >2.631 1 5855 0 0 0 0 0 0 0 0 0 0 0 0 0 >2.904 1 5855 1 2 5 0 0 0 0 0 0 0 0 0 0 > > It's in fact scrolling from 1803 to 5855 because num_finger is still == 2. > The second patch stops two-finger scrolling when the ''finger'' variable is > false. > > > > Oh, and thanks for maintaining this driver. :) i tried to contact previous > upstream but they didn't answer. Pushed, thanks a lot! Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Wrong links, files not where they're supposed to be
On Mon, Nov 24, 2008 at 11:02 AM, Adam Jackson <[EMAIL PROTECTED]> wrote: >> driver: >> xf86-input-calcomp >> > > These are not. I'll fix, thanks. > - ajax > Thank you. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how to get fake input events to a Xinput2 master device?
On Tue, Nov 25, 2008 at 09:51:34AM +1100, Daniel Stone wrote: > On Mon, Nov 24, 2008 at 07:17:52PM +0100, Christian Beier wrote: > > On Mon, 24 Nov 2008 18:50:38 +1100 > > Daniel Stone <[EMAIL PROTECTED]> wrote: > > > How about being able to create new SDs, a la uinput? > > > > Using uinput would undoubtly be the cleaner solution, but would limit > > the application to Linux and would need fiddling with udev rules for > > the right permissions in /dev/input/ and putting the user in the > > corresponding group. I think I'll stick to creating MDs on the fly and > > feeding them directly - which should be unproblematic if I keep exactly > > one event source per MD, as Peter outlined in his reply to my previous > > post. Or I'll implement both ways and leave the choice up to the > > user... Let's see... > > I meant being able to create virtual SDs on the fly: basically, uinput > for MPX. Using uinput would be the wrong way to go, IMO. You could feed "void" devices to the server, even easier if config-dbus is enabled. ATM the server doesn't provide an option to create an SD through a client request and I haven't made up my mind yet if we should. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Mon, Nov 24, 2008 at 06:50:57AM -0800, Dan Nicholson wrote: > Thanks for testing. I'll have to dig in a little more and see why that > would happen. I was mostly watching whether the map was cached at the > right time, but not really playing with different keymaps. AFAICT, it is cached at the right times, but it seems to use the wrong one. > > Just configure one keyboard to have a different layout in your fdi file > > (e.g. > > de) and start a plain server and xterm. In current master, the keyboard has > > the specified layout, with your patch it has the default layout (us). > > Can you please test and fix this? Thanks. > > Does the log report the wrong layout, or do you just find the wrong > keymap has been applied? If you run with -logverbose, does it report > that the cached keymap is used? I'll take a look, but I'd like to make > sure that I'm seeing the same issue you are. no, that's the thing. the log looks like it's all fine, but the actual keymap on the keyboard is the default one (that's on master btw, not 1.5, just to make sure). I tried with layout de (easy to test, y and z are swapped), and reverting the patch with the same setup gave me the german layout. With the patch, I always have the us layout. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Additional NULL (??) layout group with evdev+hal
On Mon, Nov 24, 2008 at 11:19:33PM +0900, Thomas Fritzsche wrote: > > Somehow this first version is broken creating the 3rd layout group. > I guess I need to put these 2 patches in my xserver that you created for: > http://bugs.freedesktop.org/show_bug.cgi?id=14373 > Or is this other case? yeah, but both of them should be in 1.5.2. Can you please check whether you have that code, or whether it's something else gone wrong? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
Peter Harris wrote: > McDonald, Michael-p7438c wrote: >> In the X protocol, there is no concept of the root window being >> obscured. > > I don't see why not. If I am running multiple desktops, the root of one > desktop may be obscured if I am viewing a different desktop. I forgot to remind you about Xsecurity/Xace. In a properly secured setup, any attempt to do an XGetImage on the root window will result in BadAccess (and no image); doing a GetImage on your own bottommost root-sized window will result in an empty image. This isn't just theoretical; SSH -X tunnels typically set this up by default, for example. In this case, you might as well imagine that the root window is obscured, at least from the perspective of your application. The obscuring is artificial, granted, but still present. Your app isn't allowed to see bits from other applications, so it doesn't. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
McDonald, Michael-p7438c wrote: > >>> I'm only doing XGetImage on the root window. >> Is your application prepared to handle undefined bits for windows that >> are not the same depth as the root? (Overlays, for example, but also >> non-sample servers make multiple depths available). > > As far as I'm aware, root windows only have one depth. I believe that > holds for every individual window as well: a window has a single depth, > which may differ from its parent's and its sibling's depths. Exactly. And XGetImage always includes inferior windows[1]. When those inferiors are a different depth, those contents of XGetImage are undefined[2]. Think about what happens when the root is depth 8, and your application intelligently picks a depth 24 visual for its display. Your monitor will display the full 24-bit image just fine, but a lossless translation for XGetImage simply isn't possible. The protocol definition doesn't even suggest an approximation. > In the X protocol, there is no concept of the root window being > obscured. I don't see why not. If I am running multiple desktops, the root of one desktop may be obscured if I am viewing a different desktop. Consider Xnest (and Xephyr), which can have its root window obscured by other windows on the host server. Consider also a virtual root that is larger than the resolution of your monitor. Traditionally, the sample implementation has saved the bits that are not visible, but there is no reason it needs to (other than performance). Peter Harris [1] Yes, that was a stupid protocol design decision. But at least the protocol designers admit it in the docs: "This request is not general-purpose... It is intended specifically for rudimentary hardcopy support." [2] http://cgit.freedesktop.org/xorg/doc/xorg-docs/plain/hardcopy/XProtocol/proto.PS.gz -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Move matrix operations from X server to pixman
Signed-off-by: Keith Packard <[EMAIL PROTECTED]>
---
configure.ac |2 +-
pixman/Makefile.am |3 +-
pixman/pixman-matrix.c | 594
pixman/pixman-utils.c | 32 ---
pixman/pixman.h| 146
5 files changed, 743 insertions(+), 34 deletions(-)
create mode 100644 pixman/pixman-matrix.c
diff --git a/configure.ac b/configure.ac
index 7937f95..063f6eb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -54,7 +54,7 @@ AC_PREREQ([2.57])
m4_define([pixman_major], 0)
m4_define([pixman_minor], 13)
-m4_define([pixman_micro], 1)
+m4_define([pixman_micro], 2)
m4_define([pixman_version],[pixman_major.pixman_minor.pixman_micro])
diff --git a/pixman/Makefile.am b/pixman/Makefile.am
index 6d5a643..c4612ea 100644
--- a/pixman/Makefile.am
+++ b/pixman/Makefile.am
@@ -26,7 +26,8 @@ libpixman_1_la_SOURCES = \
pixman-edge-imp.h \
pixman-trap.c \
pixman-compute-region.c \
- pixman-timer.c
+ pixman-timer.c \
+ pixman-matrix.c
libpixmanincludedir = $(includedir)/pixman-1/
libpixmaninclude_HEADERS = pixman.h pixman-version.h
diff --git a/pixman/pixman-matrix.c b/pixman/pixman-matrix.c
new file mode 100644
index 000..ce5d77f
--- /dev/null
+++ b/pixman/pixman-matrix.c
@@ -0,0 +1,594 @@
+/*
+ * Copyright © 2008 Keith Packard
+ *
+ * Permission to use, copy, modify, distribute, and sell this software and its
+ * documentation for any purpose is hereby granted without fee, provided that
+ * the above copyright notice appear in all copies and that both that copyright
+ * notice and this permission notice appear in supporting documentation, and
+ * that the name of the copyright holders not be used in advertising or
+ * publicity pertaining to distribution of the software without specific,
+ * written prior permission. The copyright holders make no representations
+ * about the suitability of this software for any purpose. It is provided "as
+ * is" without express or implied warranty.
+ *
+ * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
+ * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
+ * OF THIS SOFTWARE.
+ */
+
+/*
+ * Floating point matrix interfaces
+ */
+
+#include "config.h"
+#include
+#include
+#include "pixman-private.h"
+
+#define F(x) pixman_int_to_fixed(x)
+
+PIXMAN_EXPORT void
+pixman_transform_init_identity(struct pixman_transform *matrix)
+{
+ int i;
+
+ memset(matrix, '\0', sizeof (struct pixman_transform));
+ for (i = 0; i < 3; i++)
+ matrix->matrix[i][i] = F(1);
+}
+
+typedef pixman_fixed_32_32_t pixman_fixed_34_30_t;
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point_3d(struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ struct pixman_vector result;
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_48_16_t v;
+ int i, j;
+
+ for (j = 0; j < 3; j++)
+ {
+ v = 0;
+ for (i = 0; i < 3; i++)
+ {
+ partial = ((pixman_fixed_48_16_t)
transform->matrix[j][i] *
+ (pixman_fixed_48_16_t) vector->vector[i]);
+ v += partial >> 16;
+ }
+ if (v > pixman_max_fixed_48_16 || v < pixman_min_fixed_48_16)
+ return FALSE;
+ result.vector[j] = (pixman_fixed_t) v;
+ }
+ *vector = result;
+ if (!result.vector[2])
+ return FALSE;
+ return TRUE;
+}
+
+PIXMAN_EXPORT pixman_bool_t
+pixman_transform_point(struct pixman_transform *transform,
+ struct pixman_vector *vector)
+{
+ pixman_fixed_32_32_t partial;
+ pixman_fixed_34_30_t v[3];
+ pixman_fixed_48_16_t quo;
+ int i, j;
+
+ for (j = 0; j < 3; j++)
+ {
+ v[j] = 0;
+ for (i = 0; i < 3; i++)
+ {
+ partial = ((pixman_fixed_32_32_t)
transform->matrix[j][i] *
+ (pixman_fixed_32_32_t) vector->vector[i]);
+ v[j] += partial >> 2;
+ }
+ }
+ if (!v[2])
+ return FALSE;
+ for (j = 0; j < 2; j++)
+ {
+ quo = v[j] / (v[2] >> 16);
+ if (quo > pixman_max_fixed_48_16 || quo <
pixman_min_fixed_48_16)
+ return FALSE;
+ vector->vector[j] = (pixman_fixed_t) quo;
+ }
+ vector->vector[2] = pixman_fixe
Re: [PATCH] intel TV out margin configuration via xorg.conf
> On 2008.11.07 20:17:37 +0800, Robert Lowery wrote:
>> Any reason why we don't support TV out margin setting via xorg.conf?
>> It's
>> a pain using xrandr to configure after X is started (or am I missing
>> something how this should be done?)
>>
>> diff below works for me with settings like the following in xorg.conf
>> Section "Monitor"
>> Identifier "TV"
>> Option "TV Format" "576p"
>> Option "Left" "35"
>> Option "Top" "30"
>> Option "Bottom" "22"
>> Option "Right" "42"
>> EndSection
>>
>> Apologies if SquirrelMail corrupts the diff
>>
>
> yeah, that hurts. :) So I tried to fix and update your patch like below.
> Tested ok. Fine with it?
Looks good, thanks
-Rob
>
> From e6150f005023cadbb57cb67cd0aac526800869ed Mon Sep 17 00:00:00 2001
> From: Robert Lowery <[EMAIL PROTECTED]>
> Date: Tue, 25 Nov 2008 00:52:40 +0800
> Subject: [PATCH] TV: add support to set TV margins in xorg.conf
>
> ---
> man/intel.man |2 +-
> src/i830_tv.c | 32 ++--
> 2 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/man/intel.man b/man/intel.man
> index ef0337c..81a94ac 100644
> --- a/man/intel.man
> +++ b/man/intel.man
> @@ -296,7 +296,7 @@ Integrated TV output. Available properties include:
> .B BOTTOM, RIGHT, TOP, LEFT
> - margins
> .TP 2
> -Adjusting these properties allows you to control the placement of your TV
> output buffer on the screen.
> +Adjusting these properties allows you to control the placement of your TV
> output buffer on the screen. The options with the same name can also be
> set in xorg.conf with integer value.
>
> .PP
> .B TV_FORMAT
> diff --git a/src/i830_tv.c b/src/i830_tv.c
> index 09a46e9..d507a0c 100644
> --- a/src/i830_tv.c
> +++ b/src/i830_tv.c
> @@ -1691,6 +1691,8 @@ i830_tv_init(ScrnInfoPtr pScrn)
> I830OutputPrivatePtrintel_output;
> struct i830_tv_priv *dev_priv;
> uint32_t tv_dac_on, tv_dac_off, save_tv_dac;
> +char*mon_option_lst = NULL;
> +char *tv_format = NULL;
>
> if (pI830->quirk_flag & QUIRK_IGNORE_TV)
> return;
> @@ -1745,21 +1747,23 @@ i830_tv_init(ScrnInfoPtr pScrn)
>
> dev_priv->tv_format = NULL;
>
> -/* BIOS margin values */
> -dev_priv->margin[TV_MARGIN_LEFT] = 54;
> -dev_priv->margin[TV_MARGIN_TOP] = 36;
> -dev_priv->margin[TV_MARGIN_RIGHT] = 46;
> -dev_priv->margin[TV_MARGIN_BOTTOM] = 37;
> -
> if (output->conf_monitor)
> -{
> - char*tv_format;
> -
> - tv_format = xf86findOptionValue (output->conf_monitor->mon_option_lst,
> "TV Format");
> - if (tv_format)
> - dev_priv->tv_format = xstrdup (tv_format);
> -}
> -if (!dev_priv->tv_format)
> + mon_option_lst = output->conf_monitor->mon_option_lst;
> +
> + /* BIOS margin values */
> +dev_priv->margin[TV_MARGIN_LEFT] = xf86SetIntOption (mon_option_lst,
> + "Left", 54);
> +dev_priv->margin[TV_MARGIN_TOP] = xf86SetIntOption (mon_option_lst,
> + "Top", 36);
> +dev_priv->margin[TV_MARGIN_RIGHT] = xf86SetIntOption (mon_option_lst,
> + "Right", 46);
> +dev_priv->margin[TV_MARGIN_BOTTOM] = xf86SetIntOption
> (mon_option_lst,
> + "Bottom", 37);
> +
> +tv_format = xf86findOptionValue (mon_option_lst, "TV Format");
> +if (tv_format)
> + dev_priv->tv_format = xstrdup (tv_format);
> +else
> dev_priv->tv_format = xstrdup (tv_modes[0].name);
>
> output->driver_private = intel_output;
> --
> 1.5.6.5
>
>
> --
> Open Source Technology Center, Intel ltd.
>
> $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
>
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Peter Harris [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 12:54 PM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > > I'm only doing XGetImage on the root window. > > Is your application prepared to handle undefined bits for windows that > are not the same depth as the root? (Overlays, for example, but also > non-sample servers make multiple depths available). As far as I'm aware, root windows only have one depth. I believe that holds for every individual window as well: a window has a single depth, which may differ from its parent's and its sibling's depths. > Is your application prepared to handle BadMatch if randr has > rotated or > resized the root window since the last time you queried it? Those ops aren't allowed in my specfic case. But yes, I'm aware that the root window may be resized, not that it has anything to do with XGetImage returning junk. > Ah. If that is case, xorg may be returning the wrong bits, and might > need to be fixed. But it's the same Xorg in all cases. What differs is what other drivers may or may not be running on the system at the same time. > > But heck, Xorg isn't even consistant in returning junk! If I start > > Xorg+dummy on a machine running Xorg+nvidia, I get good > results. If I > > run Xorg+dummy on a machine running Xorg+intel, I get junk. If I run > > Xorg+dummy on a machine with no other X server, I get junk. What is > > Xorg+nvidia doing "wrong"? > > nvidia is doing nothing "wrong". In the case of an obscured > window, the > returned bits are undefined. "Undefined" means exactly that > there is no > such thing as a "wrong" set of bits to return. It helps to think of it > as a stream from /dev/urandom, which might (through coincidence) match > what you were expecting. > > In your case, I misunderstood what was going on. If the > windows are not > obscured, then my reasoning is faulty. In the X protocol, there is no concept of the root window being obscured. That's VT brain damage, IMNSHO. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
McDonald, Michael-p7438c wrote: > >> Basically, unless you are taking a screen shot, XGetImage is the wrong >> thing to do. And if you *are* taking a screen shot of a >> screen that has >> switched to another VT, "junk" is the correct result. > > I'm only doing XGetImage on the root window. Is your application prepared to handle undefined bits for windows that are not the same depth as the root? (Overlays, for example, but also non-sample servers make multiple depths available). Is your application prepared to handle BadMatch if randr has rotated or resized the root window since the last time you queried it? > And I strongly disagree > that "junk" is the correct result. In my example of running > Xorg+dummy_drv, how can returing junk be considered the "correct" > result? Dummy_drv's memory based framebuffer still has the pixels in it. > OK, if I'm running multiple X servers sharing the same card, then junk > might be a reasonable answer. Ah. If that is case, xorg may be returning the wrong bits, and might need to be fixed. > But heck, Xorg isn't even consistant in returning junk! If I start > Xorg+dummy on a machine running Xorg+nvidia, I get good results. If I > run Xorg+dummy on a machine running Xorg+intel, I get junk. If I run > Xorg+dummy on a machine with no other X server, I get junk. What is > Xorg+nvidia doing "wrong"? nvidia is doing nothing "wrong". In the case of an obscured window, the returned bits are undefined. "Undefined" means exactly that there is no such thing as a "wrong" set of bits to return. It helps to think of it as a stream from /dev/urandom, which might (through coincidence) match what you were expecting. In your case, I misunderstood what was going on. If the windows are not obscured, then my reasoning is faulty. >> Workaround (or, arguably, bug fix): Don't use XGetImage. > > And how is that a workaround? "Doctor, it hurts when I hit my thumb with this hammer." "So don't use a hammer, then." "And how is that a workaround?" I'm afraid I don't know *why* you are using a hammer. If you are trying to drive in a screw, I might suggest using a screwdriver instead. If you are trying to cut a length of 2x4, maybe a band saw is a better choice. Either way, I contend that XGetImage is probably not the right tool for the job. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Alan Cox [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 11:47 AM > To: Adam Jackson > Cc: McDonald, Michael-p7438c; xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > > > But we do that anyway for all the offscreen pixmaps, because unlike > > windows, we're not allowed to lose their contents. > > Sounds like another good reason to have DRI manage that and X aware > screen switching so you only have to save console stomped areas. While experimenting, I confused the VT manager somehow and I had multiple copies of Xorg+intel running successfully. Even XGetImage was returning "good" results! I believe that it worked because it was doing everything thru DRI. Unfortunately, I can't figure out how to confuse the VT manager on demand. :-( Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Peter Harris [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 11:18 AM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > Basically, unless you are taking a screen shot, XGetImage is the wrong > thing to do. And if you *are* taking a screen shot of a > screen that has > switched to another VT, "junk" is the correct result. I'm only doing XGetImage on the root window. And I strongly disagree that "junk" is the correct result. In my example of running Xorg+dummy_drv, how can returing junk be considered the "correct" result? Dummy_drv's memory based framebuffer still has the pixels in it. OK, if I'm running multiple X servers sharing the same card, then junk might be a reasonable answer. But heck, Xorg isn't even consistant in returning junk! If I start Xorg+dummy on a machine running Xorg+nvidia, I get good results. If I run Xorg+dummy on a machine running Xorg+intel, I get junk. If I run Xorg+dummy on a machine with no other X server, I get junk. What is Xorg+nvidia doing "wrong"? > Workaround (or, arguably, bug fix): Don't use XGetImage. And how is that a workaround? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
> But we do that anyway for all the offscreen pixmaps, because unlike > windows, we're not allowed to lose their contents. Sounds like another good reason to have DRI manage that and X aware screen switching so you only have to save console stomped areas. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
On Mon, 2008-11-24 at 18:17 +, Alan Cox wrote: > > Because when you don't have the VT, you don't have the hardware, so you > > can't submit commands to it. We don't preserve the framebuffer when we > > VT switch away, we just generate exposures for all windows when we > > restore X. > > > > There was some debate about this way way back in like xfree86 4.0 or so. > > I don't remember what the motivation was for what we've got now, but > > it's what we do, so... > > Speed of switching for one. Nothing like copying several megabytes of > data from a PCI/AGP card via PIO to make life suck. But we do that anyway for all the offscreen pixmaps, because unlike windows, we're not allowed to lose their contents. One more full-screen pixmap doesn't seem like that big a deal. Really you're just trading that against the speed of switching back into X, and I think the exposure storm ends up being at least comparable if not more expensive. Posit a PCI card with 10M/sec download speed and a 1280x1024x32 framebuffer. Downloading the front buffer is half a second. Re-exposure on the Radeon M7 in the laptop on my left is just about half a second. Which one do you punish? - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Adam Jackson [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 11:07 AM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: RE: XGetImage returns junk with Xorg/dummy_drv/VTs > > On Mon, 2008-11-24 at 10:19 -0700, McDonald, Michael-p7438c wrote: > > Why would it do that? X apps don't know anything about VT > switching, > > nor should they. > > Because when you don't have the VT, you don't have the > hardware, so you > can't submit commands to it. But that's not true in the general case. If I don't have vtSema, all it should mean is I'm not the current virtual terminal. I may have multiple graphics cards, each exclusively owned by a separate X server. So I believe that the meaning of vtSema got overloaded. Yes, I know that for most people, one system means one card and one VT. It's just not the case for what I need. And I'd think with PCs capable of supporting multiple graphic cards, more and more people would want to be able to run multiple X servers. > There was some debate about this way way back in like xfree86 > 4.0 or so. > I don't remember what the motivation was for what we've got now, but > it's what we do, so... Yup, kind of figured it was from the Xfree86 days. Guess I'll have to figure out how to build an X server without any VT support. Oh fun! Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
Alan Cox wrote: > Speed of switching for one. Nothing like copying several megabytes of > data from a PCI/AGP card via PIO to make life suck. Indeed. > Presumably GetImage should either block or cause a redraw into an > offscreen pixmap ? GetImage can't block while waiting for a redraw, since the app requesting the GetImage is often the same app that needs to do the redraw (and will itself be blocked waiting for a GetImage reply). But that's okay, since GetImage was effectively deprecated on day one: "This request is not general-purpose in the same sense as other graphics-related requests. It is intended specifically for rudimentary hardcopy support." GetImage contents are undefined if the window is obscured (which it certainly is if the framebuffer is gone). Presumably, GetImage should simply return a black rectangle in that case. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how to get fake input events to a Xinput2 master device?
On Mon, 24 Nov 2008 18:50:38 +1100 Daniel Stone <[EMAIL PROTECTED]> wrote: > How about being able to create new SDs, a la uinput? Using uinput would undoubtly be the cleaner solution, but would limit the application to Linux and would need fiddling with udev rules for the right permissions in /dev/input/ and putting the user in the corresponding group. I think I'll stick to creating MDs on the fly and feeding them directly - which should be unproblematic if I keep exactly one event source per MD, as Peter outlined in his reply to my previous post. Or I'll implement both ways and leave the choice up to the user... Let's see... Cheers & Thanks, Christian -- what is, is; what is not is possible. pgpAOLeb4jlfK.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
McDonald, Michael-p7438c wrote: > I'm trying to run the Xorg server using the dummy driver in the > "background" in Linux. Everything works fine as long as the dummy Xorg > has the VT "focus". If it's in the background, then XGetImage returns > junk data. XGetImage *always* returns junk data. The actual bits are highly dependant on BackingStores and/or obscuring of your particular window and/or XSECURITY and/or XACE settings. And possibly Composite settings too, although I haven't checked that particular extension for GetImage interactions. Basically, unless you are taking a screen shot, XGetImage is the wrong thing to do. And if you *are* taking a screen shot of a screen that has switched to another VT, "junk" is the correct result. Although I suppose you could argue that the "junk" should be overwritten with a regular pattern, such as that created by XaceCensorImage, as the "junk" may be a security leak. > It seems like the VT code is somehow causing the framebuffer to get > swapped out. Can someone give me a hint as to what's going on? And how > to work around it if there is a work around? Workaround (or, arguably, bug fix): Don't use XGetImage. Alternate workaround (or, arguably, bug fix): Use XGetImage only on Pixmaps, never Windows. (Ditto for the source drawable of CopyArea/CopyPlane). Potential alternate workaround, depending on what exactly you are doing: Make sure BackingStore is enabled for your particular window. As you can see on page 57 of the X protocol reference, this is the only reliable way to get the bits of an obscured window (and a window is definitely obscured if the VT has been switched). Most Linux distributions ship with BackingStore disabled, though, so this isn't viable if you want your app to run everywhere. Also, the BackingStore bit is just a hint. Even if the server claims to support the BackingStore bit, it is free to discard your BackingStore at any time, although few servers do so. Peter Harris -- Hummingbird Connectivity - A Division of Open Text Peter Harrishttp://connectivity.hummingbird.com Research and DevelopmentPhone: +1 905 762 6001 [EMAIL PROTECTED]Toll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
> Because when you don't have the VT, you don't have the hardware, so you > can't submit commands to it. We don't preserve the framebuffer when we > VT switch away, we just generate exposures for all windows when we > restore X. > > There was some debate about this way way back in like xfree86 4.0 or so. > I don't remember what the motivation was for what we've got now, but > it's what we do, so... Speed of switching for one. Nothing like copying several megabytes of data from a PCI/AGP card via PIO to make life suck. Presumably GetImage should either block or cause a redraw into an offscreen pixmap ? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Is Xephyr going to support GLX in a near future?
One more sad thing: Xephyr doesn't support GLX, which means, most likely no 3D for it's users... I would like to ask someone better informed here, if that is going to be addressed in near future? I was happy, as it seamed, Xephyr could solve all those multiseat troubles (hibernation, no console framebuffer)... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
On Mon, 2008-11-24 at 10:19 -0700, McDonald, Michael-p7438c wrote: > > Yes, it does that. When Xorg loses the VT, it empties the > > clip list for the root window. All drawing to the root window gets > > thrown away, and all readbacks from it do nothing (which looks like > > uninitialized data). > > Why would it do that? X apps don't know anything about VT switching, > nor should they. Because when you don't have the VT, you don't have the hardware, so you can't submit commands to it. We don't preserve the framebuffer when we VT switch away, we just generate exposures for all windows when we restore X. There was some debate about this way way back in like xfree86 4.0 or so. I don't remember what the motivation was for what we've got now, but it's what we do, so... - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Daniel Stone [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2008 9:43 PM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > > On Fri, Nov 21, 2008 at 03:23:03PM -0700, McDonald, > Michael-p7438c wrote: > > I'm trying to run the Xorg server using the dummy driver in the > > "background" in Linux. Everything works fine as long as the > dummy Xorg > > has the VT "focus". If it's in the background, then > XGetImage returns > > junk data. > Yeah, when you don't have vtSema, your rendering is just random crap. Why? X apps don't know (and can't find out) about VT switching. > You probably want Xvfb instead of Xorg+dummy. Ultimately I need Xorg+intel, so I was simplifying things using Xorg+dummy. Also, until Friday, I couldn't get input to work using Xvfb. Then I found out that Xvfb's modmap was garbage and that if you replace it with whatever you're using on your main display, then input works using XTEST. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: XGetImage returns junk with Xorg/dummy_drv/VTs
> -Original Message- > From: Adam Jackson [mailto:[EMAIL PROTECTED] > Sent: Monday, November 24, 2008 8:55 AM > To: McDonald, Michael-p7438c > Cc: xorg@lists.freedesktop.org > Subject: Re: XGetImage returns junk with Xorg/dummy_drv/VTs > > On Fri, 2008-11-21 at 15:23 -0700, McDonald, Michael-p7438c wrote: > > I'm trying to run the Xorg server using the dummy driver in the > > "background" in Linux. Everything works fine as long as the > dummy Xorg > > has the VT "focus". If it's in the background, then > XGetImage returns > > junk data. > Yes, it does that. When Xorg loses the VT, it empties the > clip list for > the root window. All drawing to the root window gets thrown away, and > all readbacks from it do nothing (which looks like > uninitialized data). Why would it do that? X apps don't know anything about VT switching, nor should they. > I believe some combination of -novtswitch and -sharevts should get > around this by effectively making it so the X server doesn't have a VT > at all, and thus can't lose it. Using `sudo X :1 -config /etc/X11/xvfb1.config -ac -sharevts -novtswitch &` on a RHEL5 machine with the nvidia driver and XGetImage works! Run the same command on a RHEL5.2 machine with the intel driver and XGetImage returns garbage. Unfortunately, I ultimately need to run using the Intel driver in at least three invocations of Xorg. So maybe this in an Intel driver bug? But I don't understand how the intel driver could effect a separate process using the dummy driver, other than some weird interaction with the VT switching stuff. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] fix CARD* redefinition in xf86-video-intel
Hi all, Arjan sent a patch a month ago about this build bug. Basically, bios_reader.c redefines CARD* which is defined in some versions of hw/xfree86/ddc/edid.h, but was removed when vdif.h was dropped last year. Here's my attempt to fix it, hopefully in a better way (ie, new drivers should build with older servers). Thanks -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] >From 6e8bf145b6b7449f81799581fdf5e5583a6d12ce Mon Sep 17 00:00:00 2001 From: =?utf-8?q?R=C3=A9mi=20Cardona?= <[EMAIL PROTECTED]> Date: Mon, 24 Nov 2008 13:26:27 +0100 Subject: [PATCH] xfree86: include in edid.h to define CARD16 Xmd used to be included by the now defunct vdif.h, this should fix hacks in DDX video drivers (especially -intel) --- hw/xfree86/ddc/edid.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h index a4e79da..041bbfd 100644 --- a/hw/xfree86/ddc/edid.h +++ b/hw/xfree86/ddc/edid.h @@ -12,6 +12,8 @@ #ifndef _EDID_H_ #define _EDID_H_ +#include + /* read complete EDID record */ #define EDID1_LEN 128 #define BITS_PER_BYTE 9 -- 1.6.0.4 >From cd63414bc0efa0b9f1691e28be9ddfca9fef0486 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?R=C3=A9mi=20Cardona?= <[EMAIL PROTECTED]> Date: Mon, 24 Nov 2008 13:31:20 +0100 Subject: [PATCH] include to define CARD16 needed by edid.h --- src/bios_reader/bios_reader.c |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/bios_reader/bios_reader.c b/src/bios_reader/bios_reader.c index 2a6906d..1e41778 100644 --- a/src/bios_reader/bios_reader.c +++ b/src/bios_reader/bios_reader.c @@ -38,9 +38,11 @@ #include "../i830_bios.h" -typedef uint8_t CARD8; -typedef uint16_t CARD16; -typedef uint32_t CARD32; +/* backwards compatibility with edid.h from xorg-server 1.5 and older */ +#ifndef CARD16 +#include +#endif + #define _PARSE_EDID_ #include "edid.h" -- 1.6.0.4 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: DeliverPropertyEvent() accessing unallocated memory
On Sat, 2008-11-22 at 13:07 +0100, Matthieu Herrb wrote:
> Matthieu Herrb wrote:
> > Hi,
> >
> > using OpenBSD's memory allocator (which has an option to fill free()'d
> > memory with a specific pattern) I found out that xserver 1.5.3 is
> > dumping core on exit.
>
> Same problem on git's master.
>
> >
> > This is caused by a bad pointer caused by accessing free'd memory in
> > DeliverPropertyEvent, because when the RRProperties are destroyed, the
> > associated windows have been free'd already.
> >
>
> So, no help on how to fix that? Should we just remove
> RRDeleteAllOutputProperties() since it can't work?
It does work, when outputs are deleted at runtime. It just can't work
during server shutdown since windows are already gone, so there's
nothing to deliver events to.
Something like this maybe:
--- a/randr/rrproperty.c
+++ b/randr/rrproperty.c
@@ -59,7 +59,8 @@ DeliverPropertyEvent(WindowPtr pWin, void *value)
static void RRDeliverPropertyEvent(ScreenPtr pScreen, xEvent *event)
{
-WalkTree(pScreen, DeliverPropertyEvent, event);
+if (!(dispatchException & (DE_RESET | DE_TERMINATE)))
+ WalkTree(pScreen, DeliverPropertyEvent, event);
}
void
---
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Wrong links, files not where they're supposed to be
On Sat, 2008-11-22 at 18:56 -0500, Robert Dvoracek wrote:
> > > * The source directories for 7.4 in the various directories
> > > /releases/X11R7.4/src/{app,driver,font,lib,proto,util} only contain
> > archives
> > > for the components which were updated for the new release. The other
> > > components necessary to build X.Org are missing. Strangely enough they
> > are
> > > all there in the /releases/X11R7.4/src/everything/ directory.
> > >
> > Do you have examples (or, even better, a list of missing files)? I see
> > some absolute symlinks in X11R7.4/src/app/ on annarchy, which would
> > probably break on mirrors. What url are you looking at?
>
> I'm looking at the primary sites - http://www.x.org/ and
> http://xorg.freedesktop.org/. Unless a bunch of packages were cut between
> 7.3 and 7.4,
They were.
> it looks like there are a few missing from
> /releases/X11R7.4/src/everything/ as well, such as
>
> app:
>
These are all intentional.
> driver:
> xf86-input-calcomp
>
These are not. I'll fix, thanks.
> xf86-video-cyrix
> xf86-video-imstt
> xf86-video-nsc
> xf86-video-vga
> xf86-video-via
These are intentional. imstt ought to be revived, we just never had
anyone motivated enough to port it to pciaccess. The others deserve to
stay dead.
> lib:
> libXTrap
> libXevie
> libXprintAppUtil
> libXprintUtil
> liblbxutil
> liboldX
> libxkbui
> libXp
Intentionally not in 7.4.
> proto:
> printproto
> xf86rushproto
> xproxymanagementprotocol
Intentionally not in 7.4.
> util:
> gccmakedep
> imake
> lndir
> xorg-cf-files
Intentionally not in 7.4.
- ajax
signature.asc
Description: This is a digitally signed message part
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XGetImage returns junk with Xorg/dummy_drv/VTs
On Fri, 2008-11-21 at 15:23 -0700, McDonald, Michael-p7438c wrote: > I'm trying to run the Xorg server using the dummy driver in the > "background" in Linux. Everything works fine as long as the dummy Xorg > has the VT "focus". If it's in the background, then XGetImage returns > junk data. > > It seems like the VT code is somehow causing the framebuffer to get > swapped out. Can someone give me a hint as to what's going on? And how > to work around it if there is a work around? Yes, it does that. When Xorg loses the VT, it empties the clip list for the root window. All drawing to the root window gets thrown away, and all readbacks from it do nothing (which looks like uninitialized data). I believe some combination of -novtswitch and -sharevts should get around this by effectively making it so the X server doesn't have a VT at all, and thus can't lose it. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Questions !
My Own Linux wrote: > 1. I want to look at the source of the function XCreateSimpleWindow(). I > extracted the xserver sources and greped it - but I could not find it > Where are the sources of Xlib function calls located ? > They are located in libX11, which is what you want to be looking at instead of the X Server. I doubt you'll find anything interesting in the Xlib sources since the role of the function in Xlib is simply to send a request to the X server. Also, XCreateSimpleWindow() is not a true function. It maps to XCreateWindow() which has more options and does the actual work. I don't know if XCreateSimpleWindow() is a macro or not, you can check yourself. > 2. When I create a window using XCreateSimpleWindow() function - the > window has the decoration of the Ubuntu desktop that I am using. I was > informed that window manager captures it and re-parents the current > window to a new window with the title bar as one window and the current > window as another. > > So how that happen ? How does the window manager know that I have > created a window using the raw X command ? (maybe I assume a event is > sent) . I just want to confirm ! > When the window manager starts, it sets the SubstructureRedirectMask even mask on the root window, which makes the X server redirect configuration requests (creating windows, mapping windows, changing the order of windows, etc.) on the root window be sent to the window manager before processing. The window manager can then take special action, such as creating a frame window and reparenting the client's window into that frame. You can read more about it here: http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/XLib_PG/sgi_html/ch16.html > 3. There are two structures : Display, Screen. How does the window > manager implement the Virtual Desktops ? Is there any other structure > like a VirtualScreen, Viewport ?? > Some window managers seem to take a hide and show approach to virtual desktops. Any windows not on the current virtual desktops are hidden and when you switch virtual desktops, it hides the windows from the current virtual desktop and shows the windows from the new virtual desktop. This is how KWin appears to do it. Others seem to have a large containing window that contains all the top level windows and it slides around which portion of this window contains the current virtual desktop. > 4. What is the actual role of X server ? > > Most of the work is done by window manager and other libraries. > > What I have been able to gather is : > > - It creates and manages windows > - Handles the input events > - Informs when the window needs to be redrawn. > > Am I right or I left something. > It performs drawing operations and manages initialization of hardware and interfacing with the same. > Most of the documentation on the net is old and has no information about > current releases. I am trying to understand the X server - so the many > questions that I could not find answers anywhere. > > > > > > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Use cached XKB keymap when rules haven't changed
On Sun, Nov 23, 2008 at 9:21 PM, Peter Hutterer <[EMAIL PROTECTED]> wrote: > On Sun, Nov 23, 2008 at 06:06:54PM -0800, Dan Nicholson wrote: >> Rather than compiling a new keymap every time XkbInitKeyboardDeviceStruct >> is called, cache the previous keymap and reuse it if the rules have not been >> changed. When XkbSetRulesDflts is called, the cached map is invalidated if >> it differs from the previous default rules. >> >> The map is also invalidated if named components are supplied. This could be >> fixed by caching Ktcsg from the previous run and comparing. > > looks good, but - it doesn't work. Caching and re-using seems to work but it > breaks different keymaps for different devices. Thanks for testing. I'll have to dig in a little more and see why that would happen. I was mostly watching whether the map was cached at the right time, but not really playing with different keymaps. > Just configure one keyboard to have a different layout in your fdi file (e.g. > de) and start a plain server and xterm. In current master, the keyboard has > the specified layout, with your patch it has the default layout (us). > Can you please test and fix this? Thanks. Does the log report the wrong layout, or do you just find the wrong keymap has been applied? If you run with -logverbose, does it report that the cached keymap is used? I'll take a look, but I'd like to make sure that I'm seeing the same issue you are. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Questions !
1. I want to look at the source of the function XCreateSimpleWindow(). I extracted the xserver sources and greped it - but I could not find it Where are the sources of Xlib function calls located ? 2. When I create a window using XCreateSimpleWindow() function - the window has the decoration of the Ubuntu desktop that I am using. I was informed that window manager captures it and re-parents the current window to a new window with the title bar as one window and the current window as another. So how that happen ? How does the window manager know that I have created a window using the raw X command ? (maybe I assume a event is sent) . I just want to confirm ! 3. There are two structures : Display, Screen. How does the window manager implement the Virtual Desktops ? Is there any other structure like a VirtualScreen, Viewport ?? 4. What is the actual role of X server ? Most of the work is done by window manager and other libraries. What I have been able to gather is : - It creates and manages windows - Handles the input events - Informs when the window needs to be redrawn. Am I right or I left something. Most of the documentation on the net is old and has no information about current releases. I am trying to understand the X server - so the many questions that I could not find answers anywhere. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Dinamically switch between Xinerama and Multiseat
Hello, I have 2 TFTs with each 1280x1024. Normally I work alone on the pc -> Xinerama. But sometimes my girlfriend wants to work on the pc, too. But I do not want to log out, change KDM and log in again. So I need something that works on the fly. Here is what I have this far: 1) Starting X across both TFTs. 2) DISPLAY=:0 Xephyr :1 -br +xinerama -screen 2560x1024 This lets me have one big screen where I can load KDM. 3) DISPLAY=:1 xrandr -s 1280x1024 lets me change the size to one TFT. 3.1) Starting another Xephyr on the other TFT with a small Window Manager is no big deal. > Two Xephyr, one one each TFT Now "backwards": Closing one Xephyr. 4) DISPLAY=:1 xrandr -s 2560x1024 Not a supported mode any longer. This is my problem. Starting Xephyr with 2560x1024 works fine. But after resizing it, the maximum resolution is 1600x1200. Also adding a new modeline does not help as it is accepted for the first time but not being displayed nor possible to select it. Any suggestions would be nice. -- xrandr-1.2.3 xorg-server-1.5.2 Portage 2.2_rc15 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.8_p20080602- r0, 2.6.27.6 x86_64) System uname: Linux-2.6.27.6-x86_64-AMD_Phenom-tm-_9850_Quad-Core_Processor- with-glibc2.2.5 -- Thanks Tobi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Accelerating Ogg Theora and Dirac (was: MPEG-LA / Todo list)
2008/11/24 Stan Cunningham <[EMAIL PROTECTED]>: > As for the last part about the decoder, it would be nice if all FOSS drivers > (OpenChrome, Radeon, Intel, etc) could share the same Theora and Dirac > decoder. The libs are BSD-licensed, and are present on most free Unix-likes and have no legal encumbrances for distribution with others. Firefox 3.1 will include Theora - perhaps for FF4/Gecko 2, something could be worked out for the browser to use the OS/Xorg installation where available. - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: how does x write to display cards
My Own Linux wrote: > I am doing a small project (still in learning phase). I want to know does X > server write the image to the display card memory to be shown on monitor. > > Does it use DirectFB or the Linux frame buffer ? It usually access the hardware directly, although there is a driver for fbdev. -- Glynn Clements <[EMAIL PROTECTED]> ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon vs radeonhd drivers
Alex Deucher wrote: > On Thu, Nov 13, 2008 at 7:54 AM, Simon Thum <[EMAIL PROTECTED]> wrote: >> Gene Heskett wrote: >>> But its not that simple either, cuz when running the radeon driver, I get >>> random screen blanking for 1-10 seconds at a time, and for a change it >>> doesn't seem to be tied to the time of day since its doing it right now and >>> it is 10 pm. >> I'm experiencing the exact same thing, but it doesn't happen on every >> Xorg session (about every third). >> >> It has been OK with the 6.8.0 version of the radeon driver, if it helps. > > Please try the coherent_mode output attribute and see if that helps. > If not we may need to tweak the plls for your monitor. So, again I got the issue. coherent_mode was 0. I swithed to 1, but it crept up again after 3 min or so. Then, I switched back to zero. Since then, it ran fine (a few hours now). Doesn't sound like this could help someone track it down, but anyway... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Sorry just to clarify - can't Xorg draw a gradient directly to the > pixmap over PCI, rather than migrating the pixmap out of the video > card? That was the suggestion I made in a previous mail. You can work-arround this issue by using a temporary pixmap to draw your gradient on, instead of using your gradient picture directly. However even with this tweak a lot of time in my profiles is dedicated to gradient generation and sysmem->vram copying (exaDoMoveIn). - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
2008/11/24 Clemens Eisserer <[EMAIL PROTECTED]>: >> Out of interest - how widely are gradients used? How often will a >> typical desktop use gradients? > At least when looking at all the GTK themes, gradients are used a lot. > I don't know wether QT4 uses RENDER gradients, but theme designers > there too seem to make heavy use of gradients. > > Even Java's default theme uses gradients a lot: > http://java.sun.com/developer/technicalArticles/tools/nb_guibuilder/netbeans5_5.jpg > When looking sysprof profiles, I clearly see a lot of time is spent > for gradients - and at least on i915, almost all migration done is > caused by them. Sorry just to clarify - can't Xorg draw a gradient directly to the pixmap over PCI, rather than migrating the pixmap out of the video card? John ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
> Out of interest - how widely are gradients used? How often will a > typical desktop use gradients? At least when looking at all the GTK themes, gradients are used a lot. I don't know wether QT4 uses RENDER gradients, but theme designers there too seem to make heavy use of gradients. Even Java's default theme uses gradients a lot: http://java.sun.com/developer/technicalArticles/tools/nb_guibuilder/netbeans5_5.jpg When looking sysprof profiles, I clearly see a lot of time is spent for gradients - and at least on i915, almost all migration done is caused by them. - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [IDEA] shrink xrender featureset
2008/11/23 Eric Anholt <[EMAIL PROTECTED]>: > On Sat, 2008-11-22 at 18:19 +0100, Maarten Maathuis wrote: >> Currently there exist several operations in xrender that are better >> off client side or through some other graphic api (imo). Think of >> trapezoid rasterisation, gradient rendering, etc. Doing this stuff >> client side avoids unforseen migration issues and doesn't create any >> false impressions with the api users. >> >> My suggestion would be to deprecate everything, except solid, >> composite, cursor stuff and glyphs. The idea is to stop doing >> seemingly arbitrary graphics operations that end up causing slowness >> most of the time (if not worked around "properly"). At this stage >> noone accelerates these operations, so there can be no complaints >> about that. >> >> xrender is here to stay, but there are limits to it, so let's accept >> this and move on (for other needs). >> >> How do others feel about this? > > NAK. We'll be building gradients support soon. It's a required > feature, doable in a shader, and software isn't good enough. > > Traps we don't have a concrete plan on yet, but given how widely used > they are they certainly can't be deprecated. Back when I last touched > EXA the migration for them was handled, anyway. Out of interest - how widely are gradients used? How often will a typical desktop use gradients? John ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to disable all messages printed that appear when starting Xorg?
I really dont understand why You would like to do that!! But if You really want its simple You can write a wrapper script, that just run your command and redirect everything to a file. #!/bin/sh /usr/bin/startx.old > /var/log/Xsuppress.log 2> /var/log/Xsuppress.log 2008/11/24 Mohamed AbdElwahed <[EMAIL PROTECTED]> >hi all, > I run Xorg from a linux terminal and there are a lot of messages that > appear i want to suppress all of these messeges > - > thanks in advance > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
How to disable all messages printed that appear when starting Xorg?
hi all,I run Xorg from a linux terminal and there are a lot of messages that appear i want to suppress all of these messeges- thanks in advance _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] intel TV out margin configuration via xorg.conf
On 2008.11.07 20:17:37 +0800, Robert Lowery wrote:
> Any reason why we don't support TV out margin setting via xorg.conf? It's
> a pain using xrandr to configure after X is started (or am I missing
> something how this should be done?)
>
> diff below works for me with settings like the following in xorg.conf
> Section "Monitor"
> Identifier "TV"
> Option "TV Format" "576p"
> Option "Left" "35"
> Option "Top" "30"
> Option "Bottom" "22"
> Option "Right" "42"
> EndSection
>
> Apologies if SquirrelMail corrupts the diff
>
yeah, that hurts. :) So I tried to fix and update your patch like below.
Tested ok. Fine with it?
From e6150f005023cadbb57cb67cd0aac526800869ed Mon Sep 17 00:00:00 2001
From: Robert Lowery <[EMAIL PROTECTED]>
Date: Tue, 25 Nov 2008 00:52:40 +0800
Subject: [PATCH] TV: add support to set TV margins in xorg.conf
---
man/intel.man |2 +-
src/i830_tv.c | 32 ++--
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/man/intel.man b/man/intel.man
index ef0337c..81a94ac 100644
--- a/man/intel.man
+++ b/man/intel.man
@@ -296,7 +296,7 @@ Integrated TV output. Available properties include:
.B BOTTOM, RIGHT, TOP, LEFT
- margins
.TP 2
-Adjusting these properties allows you to control the placement of your TV
output buffer on the screen.
+Adjusting these properties allows you to control the placement of your TV
output buffer on the screen. The options with the same name can also be set in
xorg.conf with integer value.
.PP
.B TV_FORMAT
diff --git a/src/i830_tv.c b/src/i830_tv.c
index 09a46e9..d507a0c 100644
--- a/src/i830_tv.c
+++ b/src/i830_tv.c
@@ -1691,6 +1691,8 @@ i830_tv_init(ScrnInfoPtr pScrn)
I830OutputPrivatePtrintel_output;
struct i830_tv_priv*dev_priv;
uint32_t tv_dac_on, tv_dac_off, save_tv_dac;
+char*mon_option_lst = NULL;
+char *tv_format = NULL;
if (pI830->quirk_flag & QUIRK_IGNORE_TV)
return;
@@ -1745,21 +1747,23 @@ i830_tv_init(ScrnInfoPtr pScrn)
dev_priv->tv_format = NULL;
-/* BIOS margin values */
-dev_priv->margin[TV_MARGIN_LEFT] = 54;
-dev_priv->margin[TV_MARGIN_TOP] = 36;
-dev_priv->margin[TV_MARGIN_RIGHT] = 46;
-dev_priv->margin[TV_MARGIN_BOTTOM] = 37;
-
if (output->conf_monitor)
-{
- char*tv_format;
-
- tv_format = xf86findOptionValue (output->conf_monitor->mon_option_lst,
"TV Format");
- if (tv_format)
- dev_priv->tv_format = xstrdup (tv_format);
-}
-if (!dev_priv->tv_format)
+ mon_option_lst = output->conf_monitor->mon_option_lst;
+
+ /* BIOS margin values */
+dev_priv->margin[TV_MARGIN_LEFT] = xf86SetIntOption (mon_option_lst,
+ "Left", 54);
+dev_priv->margin[TV_MARGIN_TOP] = xf86SetIntOption (mon_option_lst,
+ "Top", 36);
+dev_priv->margin[TV_MARGIN_RIGHT] = xf86SetIntOption (mon_option_lst,
+ "Right", 46);
+dev_priv->margin[TV_MARGIN_BOTTOM] = xf86SetIntOption (mon_option_lst,
+ "Bottom", 37);
+
+tv_format = xf86findOptionValue (mon_option_lst, "TV Format");
+if (tv_format)
+ dev_priv->tv_format = xstrdup (tv_format);
+else
dev_priv->tv_format = xstrdup (tv_modes[0].name);
output->driver_private = intel_output;
--
1.5.6.5
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X forcing WheelEmulation
Dne nedelja 23. novembra 2008 je Peter Hutterer napisal(a): > I'll push you over to bugzilla again, please attach the Xorg.log and the > output of lshal. I think the latter is the key here. I already wanted to ask you whether I should ;) https://bugs.freedesktop.org/show_bug.cgi?id=18681 > Could be that your device (like many wireless receivers) creates two > devices, one mouse and one keyboard. And it gets the same name > because..it's so much fun after all. I think this is the case, yes. It produces two events and for some bizzare reason one has support for 'us' keyboard layout O_o ...well, we should better move this discussion to the bugzilla, I suppose. Cheers, Matija -- gsm: +386 41 849 552 e-mail: [EMAIL PROTECTED] www: http://matija.suklje.name aim: hookofsilver icq: 110183360 jabber/g-talk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] yahoo: matija_suklje GPG/PGP fingerprint: FB64 FFAF B8DA 5AB5 B18A 98B8 2B68 0B51 0549 D278 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
