Re: candidate patches for server-1.5-branch inclusion
Hi, I'd like to suggest to have a look at http://bugs.freedesktop.org/show_bug.cgi?id=18204 I think the part of https://bugs.freedesktop.org/attachment.cgi?id=19848 that refers to xf86pciBus.c should be applied to both git master and included into branch 1.5. Assume a PCI resource at 0x0005/65536. Without that patch this is erroneously reported as 0x0005/0 on 32Bit LE systems (at least on x86), or as 0x/327680 on 32Bit BE systems. Quite confusing! Regards, Peter Breitenlohner [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Mouse button problems using Logitech NX80
Dne sreda 12. novembra 2008 je Peter Hutterer napisal(a): there's a chance that this is done automatically to accommodate for the left-handed/right-handed mouse setting. IIRC gnome does something similar. I suspect this bug is responsible for this mess: http://bugs.kde.org/show_bug.cgi?id=68372 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
Intel driver on Ubuntu 8.10
I'm running an 945GM on Ubuntu 8.10 which uses version 2.4.1 of the Intel driver. I'm getting occasional tearing on HD video that I didn't get on Ubuntu 8.04. I've seen some reports of tearing on this list, but don't known if there is a known problem in 2.4.1. I would build Intel 2.5 and give it a try, but Ubuntu uses libdrm 2.3.1 and Intel 2.5 need libdrm 2.4.x. Is there a version of the Intel driver that would would work with libdrm 2.3.1 that would work better than Intel 2.4.1? If not, would I break anything else building libdrm 2.4.1 replacing libdrm 2.3.1, and running Intel 2.5? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg over Linux vfb Problem
On Wed, 2008-11-12 at 19:03 +0800, Leandro Galvez wrote: Hi All, I am trying to run Xorg on my arm target device. It has no physical display device so I just enabled linux virtual framebuffer. But when I try to run the xserver, I get the message Cannot open virtual console 2. How do I get rid of this fatal error message preventing me to startup the Xorg server. Attached is my configuration file and the log file created by running Xorg :98 -nolisten tcp. Did I miss anything? Or is it just my command line? What is this virtual console anyway? Do I need to map my fb0 to it and how? Hope somebody can help me here. You probably built the kernel without virtual terminal support? Really not sure what the right thing to do there is though. - 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
Xorg over Linux vfb Problem
Hi All, I am trying to run Xorg on my arm target device. It has no physical display device so I just enabled linux virtual framebuffer. But when I try to run the xserver, I get the message Cannot open virtual console 2. How do I get rid of this fatal error message preventing me to startup the Xorg server. Attached is my configuration file and the log file created by running Xorg :98 -nolisten tcp. Did I miss anything? Or is it just my command line? What is this virtual console anyway? Do I need to map my fb0 to it and how? Hope somebody can help me here. By the way, I am not using Xvfb as I still want other applications to bypass the X window system. So I am using Linux virtual frame buffer module, not the Xvfb Thanks and best regards, Andy logs Description: Binary data xorg.conf Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon vs radeonhd drivers
On Wednesday 12 November 2008, Matthias Hopf wrote: On Nov 11, 08 14:02:00 -0500, Gene Heskett wrote: Anyway, where is (url to sub) the radeondh list? To subscribe, e-mail: [EMAIL PROTECTED] But that address rejected my mail, several times. But, I finally found a good address got it done. Now I need to post about it. Thanks. -- 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) And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. -- Linus Torvalds ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] candidate patches for server-1.5-branch inclusion
Le 08/11/2008 01:58, Maarten Maathuis a écrit : This commit fixed that issue: http://cgit.freedesktop.org/xorg/xserver/commit/?id=21c116219cd5c6845a0955f2d88fdb5fab5c17cf Thanks for follow-up, Maarten. I've added this patch to the branch. For those who might be interested, I've rebased the EXA backport branch on top of xorg-server-1.5.3 and it's still available at the same location. http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch) Could this branch be considered for inclusion later on? Thanks Rémi ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: System freeze - is X the reason?
Hi Alex, I am now on AGP 4x and AGP Fastwrite=enabled in BIOS. Had a system freeze yesterday while screensaver was running. But I could not find anything in the usual log files... I will now see if it happens again. Regards Jürgen --- Alex Deucher [EMAIL PROTECTED] schrieb am Mo, 10.11.2008: Von: Alex Deucher [EMAIL PROTECTED] Betreff: Re: System freeze - is X the reason? An: [EMAIL PROTECTED] CC: xorg@lists.freedesktop.org Datum: Montag, 10. November 2008, 16:23 On Mon, Nov 10, 2008 at 3:06 AM, Juergen Gaida [EMAIL PROTECTED] wrote: Alex, ah, ok, wasnt sure about any...sometimes a problem for non-native EN'ers. I will give it a try. Is there some explanation behind these switches? Option DRI False Disables 3D support and use of the drm for command submission. Option AGPMode 4 force the AGP mode to 4x (default is whatever the hw is set to by the bios) Option BusType PCI Force use of PCI gart rather than AGP gart What is then about all the acceleration (3D, Direct???) of the card and the so called compositor... (I am quite new to Linux, so I am not used to this terminology and all that stuff). DRI support (3D) is required for GL-based compositors like compiz. Alex Thanks in advance. Regards Jürgen --- Alex Deucher [EMAIL PROTECTED] schrieb am Mo, 10.11.2008: Von: Alex Deucher [EMAIL PROTECTED] Betreff: Re: System freeze - is X the reason? An: [EMAIL PROTECTED] CC: xorg@lists.freedesktop.org Datum: Montag, 10. November 2008, 6:33 On Sun, Nov 9, 2008 at 3:42 PM, Juergen Gaida [EMAIL PROTECTED] wrote: Alex, somewhat later than expected, but... Finally, my Zenwalk is up and running since some hours... What I did: 1. Went in MB BIOS and set AGP Speed to 4x (instead of 8x (was before) or automatic) 2. Applied the changes you proposed in Xorg.conf (all 3 lines in the graphic card device section) So, what did the trick? How can I/we get to the point to know which of the settings makes the system stable or the opposite? Try each setting (driver and bios) individually. The options I suggested: Option DRI False Option AGPMode 4 Option BusType PCI only have an effect individually. Alex Any hint where to start and any 'stress test' to get a result sooner than after hours or days? Thank you so far! Best regards Jürgen --- Alex Deucher [EMAIL PROTECTED] schrieb am Fr, 7.11.2008: Von: Alex Deucher [EMAIL PROTECTED] Betreff: Re: System freeze - is X the reason? An: [EMAIL PROTECTED] CC: xorg@lists.freedesktop.org Datum: Freitag, 7. November 2008, 0:00 On Thu, Nov 6, 2008 at 5:58 PM, Juergen Gaida [EMAIL PROTECTED] wrote: Alex, I will try, but its midnite, so maybe later on Friday. No problem. Other observation: When the system is getting off from pute Text output, some messages get fancy letters (looks like everything kyrillic and all kind of extra signs). Does it mean anything? the vga fonts may not be restored properly. Alex Thank you so far jpg --- Alex Deucher [EMAIL PROTECTED] schrieb am Do, 6.11.2008: Von: Alex Deucher [EMAIL PROTECTED] Betreff: Re: System freeze - is X the reason? An: [EMAIL PROTECTED] CC: xorg@lists.freedesktop.org Datum: Donnerstag, 6. November 2008, 23:33 On Thu, Nov 6, 2008 at 5:21 PM, Juergen Gaida [EMAIL PROTECTED] wrote: Hi, I am having serious trouble in getting Zenwalk 5.2 running on my machine - currently the only Linux running is the Knoppix 4.0 Live-CD (I have tested several). Zenwalk 5.2 installs, but freezes randomly, but soon. The Xorg.O.log tells a lot, but I dont understand lot of this stuff. However, at the end of the log, there is a tossed event and some other lines which tell me no good. But where to start solving the problem - if thats the cause of freezing the system. I have put the log file on pastebin: http://pastebin.com/m23e8d2d5 It could be. Do any of the following option help (add them to the device section of your config): Option DRI False Option AGPMode 4 Option BusType PCI Alex ___ 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 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list
Re: Intel driver on Ubuntu 8.10
On Wed, Nov 12, 2008 at 11:17:32AM -0500, Ken Mandelberg wrote: I'm running an 945GM on Ubuntu 8.10 which uses version 2.4.1 of the Intel driver. I'm getting occasional tearing on HD video that I didn't get on Ubuntu 8.04. I've seen some reports of tearing on this list, but don't known if there is a known problem in 2.4.1. Did Ubuntu 8.04 use the hardware overlay by default? Does 8.10 use the textured one? -- Matthew Garrett | [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
4 displays : move windows
Hello, I have a Nvidia graphic board which allows to connect 4 screens. I would like to switch display like I want, for example : all the windows of the second screen move to the third screen and the windows of the third move to the second. I've tried xrandr, but it's not possible to use it with the Nvidia property drivers it works only with the Xorg Nvidia drivers, but performance are very slow. And there is a problem with the mouse : xrandr switch physically the screen or I just want to move the windows of the display. I've also tried xmove but it doesn't work with glx (I must move video player) and it dated of 1994... Is there other tools to do it ? Thanks, Scorbo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: radeon vs radeonhd drivers
On Nov 11, 08 14:02:00 -0500, Gene Heskett wrote: Anyway, where is (url to sub) the radeondh list? To subscribe, e-mail: [EMAIL PROTECTED] Maybe check on the radeonhd mailing list, you're more likely getting support over there. If you're running on git, you might want to think about reporting a bug in bugzilla. No git, x is straight F8. Kernels I bleed from, copiously at times, currently 2.6.28-rc3 with a patch to control the wilder swappiness which seems to be working fine. It's just the driver I'm talking about. The X version shouldn't matter that much, and as radeon did work with that respect for you, I guess the version is good enough. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
XDMCP / Gnome / KDE / Data transfer / GTK QT / Xorg extension
Hello, We are in process to migrate our Thin client to a new Linux install and we are facing a problem : Problem : We experience very slow scroll speed (lets say, cat /var/log/messages) in Gnome terminal via XDMCP. (1M file : 1.5 minute to display) Prognostic : We don't know exactly why this is happening. We suspect GTK/QT handling of bitmap or vector to be a problem. This is maybe due to Xorg extension. Observation : * Under Konsole (KDE/QT3) we are able to display a 1M file in about 1.3 second (very smooth scrolling). * Under Terminal (Gnome/GTK) we display the same file in a full screen Terminal in about 1.5 minute. * When displaying the text file via Konsole, the thin client receive about 2Megs of data from the server. * When displaying the text file via Terminal, the thin client receive about 9 to 15Megs of data from the server. Setup : On the thin client we use ... X Protocol Version 11, Revision 0, Release 7.1.1 Kernel 2.6.18-92.1.17.el5 Gnome 2.16 KDE 3.5 On the fat server ... X Protocol Version 11, Revision 0, Release 6.8.2 Kernel 2.6.9-78.0.1.ELsmp Gnome 2.8 KDE 3.3 Question : We would like to know if this could be related to X protocol or the way things are handled when drawing text ? Note that we are able with Ubuntu 8.04 to get a better performance (still, 10 times higher with Terminal then Konsole, but good (11 seconds). Thank you in advance ! -- Jean-Francois Bouchard Note in the log file on the thin client we see the following extension loading : (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTANDARD (II) Loading extension BIG-REQUESTS (II) Loading extension SYNC (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XC-MISC (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-Misc (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension TOG-CUP (II) Loading extension Extended-Visual-Information (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Loading extension DOUBLE-BUFFER (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Loading extension GLX (II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Loading extension RECORD (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Loading extension XFree86-DRI (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/3] enable HDMI audio output for HDMI monitors V2
On 2008.11.07 14:23:38 +0800, Wu Fengguang wrote: Hello, We can now enjoy music on HDMI monitors that are attached to Intel G35/G45 chipsets with the following X.org intel driver patches [PATCH 1/3] introduce i830_hdmi_priv.has_hdmi_sink [PATCH 2/3] enable Intel G45 integrated HDMI audio output [PATCH 3/3] enable Intel G35 SDVO HDMI audio output _and_ the corresponding ALSA patch posted at http://mailman.alsa-project.org/pipermail/alsa-devel/2008-November/012158.html The patches are tested OK on Intel DG45ID board, HP 2230s notebook and ASUS P5E-VM board. Pushed xf86-video-intel patches. Thanks! If you have HDMI output with intel graphics chips, you can test this now. - alsa patch is within above mail, or get it from git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git - after loading snd_hda_intel, 'aplay -l' should give you a list of devices that contains Intel HDMI device. Use that device for PCM. Current supports G35/G45/GM45. - build xf86-video-intel git master to enable HDMI audio within video driver. Since the HDMI audio requires both audio and video driver support to function well, I'd like to provide an overview here. 1) driver components: A) ALSA: audio driver (the above link) B) Xorg: audio output enabling (this patchset) C) Xorg: EDID/ELD information (patches to be submitted by Ma Ling) 2) summary of the feature sets: - basic 2-channel audio: (A) is required, (B) is mostly required, (C) is not needed - 2+ multichannel audio: not tested yet; in theory we need (C) to get HDMI monitor's speaker allocation configuration; there are also bandwidth constraints that should be coordinated between audio/video drivers in the future. - non-LPCM audio: not tested yet; need more work in ALSA code. 3) summary of the work flow: - basic audio output: (A) and (B) - ALSA HDMI driver: enable pin out and unmute - ALSA HDMI driver: fill audio infoframe and enable its transmission - Xorg intel driver: enable audio output - ELD info for advanced audio capabilities: (A) and (C) - Xorg xserver: get/parse/store EDID extensions - Xorg xserver: transform EDID into ELD - Xorg intel driver: feed ELD to hardware - Xorg intel driver: set ELD-Valid flag to inform audio driver of new ELD - ALSA HDMI driver: response to unsolicited response triggered by ELDV - ALSA HDMI driver: get ELD from hardware - ALSA HDMI driver: parse and show ELD info - ALSA HDMI driver: update hardware capabilities/constraints according to ELD (TBD) That describes my understandings of HDMI audio, comments and discussions are warmly welcome. Thank you, Fengguang -- -- 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: Synaptics patch: orientation
On Tue, Nov 11, 2008 at 01:27:34PM +0100, Mildred Ki'Lya wrote:
Well, I don't really know how to creates patch series using git. It was
easier for me to create a repository I made available on github:
git://github.com/mildred/xorg-synaptics-orientation-patch.git
http://github.com/mildred/xorg-synaptics-orientation-patch/
git-format-patch HEAD~4 (for the last 4 patches)
git-format-patch -n HEAD~4 (to create a [PATCH 1/4] series)
Then send these patches to the list (e.g. with git-send-email). Reason being
is that it's easier to quote and point out things to change.
Now, for the suggested changes below: the easiest way is to go
edit
git-commit
edit
git-commit
edit
git-commit
git rebase -i HEAD~8 (for the last 8 commits)
git-format-patch HEAD~4
then rearrange the commits, and squash them appropriately that you end up with
the semantically correct ones again. Just play around with git rebase -i a
bit, you'll get used to it quite quickly.
Once you're done, please resend the patches.
From 3a4cb5a4e3b2856d3aba4f9abfb9732b555494bf Mon Sep 17 00:00:00 2001
From: Mildred Ki'Lya mildred593(at)online.fr
Date: Tue, 11 Nov 2008 13:02:36 +0100
Subject: [PATCH] Added Orientation option
Changed bits of code all around to handle that properly. Especially in the
function ComputeDeltas() and HandleScrolling(). Those two functions convert
(using helper functions that I've added) the hw-x and hw-y coordinates to
oriented_x and oriented_y coordinates. The angle used for circular scrolling
do not use oriented coordinates as i've taught it was not necessary, but I
haven't tested it though (i don't use circular scrolling).
Moreover, in the function HandleState(), the variable edge contains how the
oriented edge. So the functions that use the edge are automatically oriented.
This is useful for HandleTap(). The buttons in the corners of the pads are
oriented without effort.
I like extensive commit messages where appropriate, but these ones are a bit
noisy. There's a lot of stuff that is obvious through the code, so shortening
it down to what is not immediately obvious would be good.
That goes for all three commits.
+.TP
+.BI Option \*qOrientation\*q \*q integer \*q
+This option can be used to change the orientation of the trackpad and can
... This option changes the orientation ...
+takes values from 0 to 3. The default value 0 implies a normal orientation,
+other values can be used to have respectively an orientation set to the
+left, an inverted orientation, and an orientation set to the right.
+This may be useful in combinaison with the orientation option of the XRandR
^^ typo
+extension. You may notice that the values used are the same to the values
+used by XRandR.
Again, please keep it short and to-the point. e.g. the second-to-last sentence
is superfluous, last one can be shortened (no You may notice).
@@ -1593,6 +1649,9 @@ HandleScrolling(SynapticsPrivate *priv, struct
SynapticsHwState *hw,
{
SynapticsSHM *para = priv-synpara;
int delay = 10;
+int oriented_x = hw-x, oriented_y = hw-y;
Just use x, y instead of oriented_x, oriented_y please.
edge = edge_detection(priv, hw-x, hw-y);
+edge = HandleEdgeOrientation(para-orientation, edge);
can we merge that into edge_detection so we don't have separate calls?
Missing from this patch is the code to readjust the valuators if the
orientation was specified at startup.
i.e. if option Orientation is set, change the xf86InitValuatorAxisStruct
around accordingly so the ranges are correct.
we can't do anything about run-time changes, but at least it should be correct
for the startup setting.
Also, if the orientation is to be changed at runtime, it should have property
support. You can provide that as a separate patch if you want to.
From 3c16621ca139ea6c4ef121da9a245c5456fe59ec Mon Sep 17 00:00:00 2001
From: Mildred Ki'Lya mildred593(at)online.fr
Date: Tue, 11 Nov 2008 13:11:58 +0100
Subject: [PATCH] Added DontReportSize option
Replace as ReportSize option, set to TRUE by default.
Perhaps there is a way to change the trackpad dimentions when we change
orientation, but I don't know enough of the Worg internals to do that.
there isn't. not at runtime anyway.
+Along with this option, you might be interested to enable the DontReportSize
+option. Read its documentation to know why.
replace with See also: ReportSize
+.
+.TP
+.BI Option \*qDontReportSize\*q \*q boolean \*q
+This option prevent the synaptics driver from reporting the size of the
trackpad
+to Xorg. Xorg can use this information to amplify the movements in one
+direction. For example, if your trackpad is wider than higher, Xorg will
speed
+up your vertical movements. For example, moving the mouse cursor every two
+pixels when synaptics told Xorg that there was a movement on one unit along
the
+y axis.
+.
+This is particularly useful with the Orientation option which effectively
swaps
Re: Xrecord patch for syndaemon
On Tue, Nov 11, 2008 at 09:42:52PM +0100, Andre Herms wrote:
Sorry for the long delay. I was waiting for the git head to get in a
consistent state without the ugly Xrecord patch (version 1).
Thanks. Please submit your patch as a git commit (git-format-patch HEAD^)
though so it can be quickly applied with your name and your commit msg.
Attached is a cleaned up version of the Xrecord patch. Most comments have
been
included. The following two remain.
New dependency (debian x11proto-record-dev) not listed?
Where should it be listed?
configure needs to require recordproto.
background and printf... there are debug and info functions to use.
Goes for all instances of this construct.
Yes, we should add some kind of debug and info functions. However, there are
currently no such functions available in syndaemon. Adding these should be
done by another patch, not this one.
I agree. leave it as it is.
it's looking good, but enlighten me please why we need an extra data
connection for xrecord? Is that a xrecord requirement? After all, the original
connection is only used for an XGetModifierMapping call and then no longer.
@@ -333,11 +532,16 @@ main(int argc, char *argv[])
fclose(fd);
}
}
-
-setup_keyboard_mask(display, ignore_modifier_keys);
-
-/* Run the main loop */
-main_loop(display, idle_time, poll_delay);
-
+#ifdef HAVE_XRECORD
+if (use_xrecord check_xrecord(display)) {
+ record_main_loop(display, idle_time);
+} else
+#endif /* HAVE_XRECORD */
+ {
+ setup_keyboard_mask(display, ignore_modifier_keys);
+
+ /* Run the main loop */
+ main_loop(display, idle_time, poll_delay);
+ }
return 0;
}
I'd prefer if we could print out a warning if we have use_xrecord set but
check_xrecord() fails. At least so in daemon mode.
Cheers,
Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] dix: don't store enter/leave and focus semaphores in a devPrivate.
From: Peter Hutterer [EMAIL PROTECTED]
We need them for each window, every time a window is allocated. Storing them
in a devPrivate is the wrong thing to do.
This also removes the unused ENTER_LEAVE_SEMAPHORE_ISSET macro.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
dix/events.c|8 ++--
dix/window.c|6 ++
include/input.h | 17 +++--
include/windowstr.h | 18 ++
4 files changed, 13 insertions(+), 36 deletions(-)
diff --git a/dix/events.c b/dix/events.c
index 33936bd..ae38f24 100644
--- a/dix/events.c
+++ b/dix/events.c
@@ -6266,13 +6266,11 @@ ExtGrabDevice(ClientPtr client,
int
EnterLeaveSemaphoresIsset(WindowPtr win)
{
-FocusSemaphoresPtr sem;
int set = 0;
int i;
-sem = (FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey);
for (i = 0; i (MAXDEVICES + 7)/8; i++)
-set += sem-enterleave[i];
+set += win-enterleave[i];
return set;
}
@@ -6283,13 +6281,11 @@ EnterLeaveSemaphoresIsset(WindowPtr win)
int
FocusSemaphoresIsset(WindowPtr win)
{
-FocusSemaphoresPtr sem;
int set = 0;
int i;
-sem = (FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey);
for (i = 0; i (MAXDEVICES + 7)/8; i++)
-set += sem-focusinout[i];
+set += win-focusinout[i];
return set;
}
diff --git a/dix/window.c b/dix/window.c
index 1a28d27..ff5ba4a 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -271,8 +271,6 @@ BoolenableBackingStore = FALSE;
static void
SetWindowToDefaults(WindowPtr pWin)
{
-FocusSemaphoresPtr sem;
-
pWin-prevSib = NullWindow;
pWin-firstChild = NullWindow;
pWin-lastChild = NullWindow;
@@ -302,8 +300,8 @@ SetWindowToDefaults(WindowPtr pWin)
pWin-redirectDraw = RedirectDrawNone;
pWin-forcedBG = FALSE;
-sem = xcalloc(1, sizeof(FocusSemaphoresRec));
-dixSetPrivate(pWin-devPrivates, FocusPrivatesKey, sem);
+memset(pWin-enterleave, 0, sizeof(pWin-enterleave));
+memset(pWin-focusinout, 0, sizeof(pWin-focusinout));
#ifdef ROOTLESS
pWin-rootlessUnhittable = FALSE;
diff --git a/include/input.h b/include/input.h
index 0d348ec..a41affd 100644
--- a/include/input.h
+++ b/include/input.h
@@ -92,18 +92,10 @@ SOFTWARE.
/* Used for enter/leave and focus in/out semaphores */
#define SEMAPHORE_FIELD_SET(win, dev, field) \
-{ \
-FocusSemaphoresPtr sem; \
-sem = (FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey); \
-sem-field[dev-id/8] |= (1 (dev-id % 8)); \
-}
+(win)-field[(dev)-id/8] |= (1 ((dev)-id % 8)); \
#define SEMAPHORE_FIELD_UNSET(win, dev, field) \
-{ \
-FocusSemaphoresPtr sem; \
-sem = (FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey); \
-sem-field[dev-id/8] = ~(1 (dev-id % 8)); \
-}
+(win)-field[(dev)-id/8] = ~(1 ((dev)-id % 8));
#define ENTER_LEAVE_SEMAPHORE_SET(win, dev) \
SEMAPHORE_FIELD_SET(win, dev, enterleave);
@@ -111,9 +103,6 @@ SOFTWARE.
#define ENTER_LEAVE_SEMAPHORE_UNSET(win, dev) \
SEMAPHORE_FIELD_UNSET(win, dev, enterleave);
-#define ENTER_LEAVE_SEMAPHORE_ISSET(win, dev) \
-((FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey))-enterleave[dev-id/8] (1 (dev-id % 8))
-
#define FOCUS_SEMAPHORE_SET(win, dev) \
SEMAPHORE_FIELD_SET(win, dev, focusinout);
@@ -121,7 +110,7 @@ SOFTWARE.
SEMAPHORE_FIELD_UNSET(win, dev, focusinout);
#define FOCUS_SEMAPHORE_ISSET(win, dev) \
-((FocusSemaphoresPtr)dixLookupPrivate(win-devPrivates,
FocusPrivatesKey))-focusinout[dev-id/8] (1 (dev-id % 8))
+(win)-focusinout[(dev)-id/8] (1 ((dev)-id % 8))
typedef unsigned long Leds;
typedef struct _OtherClients *OtherClientsPtr;
diff --git a/include/windowstr.h b/include/windowstr.h
index 3beb01c..159ee36 100644
--- a/include/windowstr.h
+++ b/include/windowstr.h
@@ -188,6 +188,12 @@ typedef struct _Window {
#ifdef ROOTLESS
unsigned rootlessUnhittable:1; /* doesn't hit-test */
#endif
+/* Used to maintain semantics of core protocol for Enter/LeaveNotifies and
+ * FocusIn/Out events for multiple pointers/keyboards. Each device ID
+ * corresponds to one bit. If set, the device is in the window/has focus.
+ */
+charenterleave[(MAXDEVICES + 7)/8];
+charfocusinout[(MAXDEVICES + 7)/8];
} WindowRec;
/*
@@ -244,17 +250,5 @@ typedef struct _ScreenSaverStuff {
extern int screenIsSaved;
extern ScreenSaverStuffRec savedScreenInfo[MAXSCREENS];
-extern DevPrivateKey FocusPrivatesKey;
-
-/* Used to maintain semantics of core protocol for Enter/LeaveNotifies and
- * FocusIn/Out events for multiple pointers/keyboards.
- *
- * Each device ID corresponds to one bit. If set, the device is in the
- * window/has focus.
- */
-typedef struct _FocusSemaphores {
-charenterleave[(MAXDEVICES + 7)/8];
-char
Re: [PATCH] dix: don't store enter/leave and focus semaphores in a devPrivate.
On Thu, Nov 13, 2008 at 03:11:45PM +1000, Peter Hutterer wrote: From: Peter Hutterer [EMAIL PROTECTED] We need them for each window, every time a window is allocated. Storing them in a devPrivate is the wrong thing to do. Change we can believe in. Signed-off-by: Daniel Stone [EMAIL PROTECTED] signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Does libpciaccess support two screen share one pci clone mode ?
Dear All: Recently I study libpciaccess, found pci_device_map_range function, when map the same physical address and the same size will failed. If we use libpciaccess and want support two screen which share one pci, they are mmio base is the same physical address and the size is the same, when the second screeninit goto pci_device_map_range, screeninit will failed. And we can not light device. I want to ask two question: 1. Does the libpciaccess support two screen share one pci ? 2. If not support, we can do same issue in 2D driver , but I can see the nv and intel do nothing , it confused me a lot. If anyone know , please help me , thanks a lot ! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
ConfigureNotify - Are x,y parent-relative or root-relative?
On Nov 12, 2008, at 15:51, George Staplin wrote:
In the tarball I've attached there is a withdraw_remap.tcl that I
run with wish8.5 for X11 from macports.
If you have it initially mapped, and drag it to another position
before it becomes unmapped (by pressing Begin), and then it's mapped
again, it always seems to map in the +0+0 corner. I think it should
probably keep the previous x,y position. There don't seem to be any
hints set that request +0+0.
Hmm... interesting. Do you know if this worked with the old quartz-
wm? If so, then it's probably somehow related to the gravity
changes... but xwininfo -all doesn't show the gravity bit set, so it
should be acting the same as before... interesting...
This may have something to do with my not 100% understanding what x
and y are supposed to be in the ConfigureNotify and ConfigureRequest
events. (can someone please chime in and fix my brain, thanks)
The documentation says that they are supposed to be the x and y
relative to the parent window (ie the upper left of the frame):
The x and y members are used to set the window's x and y coordinates,
which are relative to the parent's origin and indicate the position of
the upper-left outer corner of the window. The width and height
members are used to set the inside size of the window, not including
the border, and must be nonzero.
but that dosen't seem to be the case. The following is from
metacity's test-gravity.c:
if(!ev.xconfigure.send_event) {
XTranslateCoordinates(d, windows[i],
DefaultRootWindow (d),
0, 0,
window_rects[i].x,
window_rects[i].y,
ignored);
} else {
window_rects[i].x = ev.xconfigure.x;
window_rects[i].y = ev.xconfigure.y;
}
which makes it seem that the x and y are global when from an
XSendEvent() but parent-relative when from an
XConfigureNotify()..?!?.. (/slap whoever convoluted this beyond
recognition)
When we send the ConfigureNotify event in quartz-wm, we actually need
to send the x,y relative to the root window or we get the wrong
positions in that above test app (and also wine has some issues that
you can see clicking on the smiley in winemine):
- (void) send_configure {
XEvent e;
e.type = ConfigureNotify;
e.xconfigure.display = x_dpy;
e.xconfigure.event = _id;
e.xconfigure.window = _id;
e.xconfigure.x = _xattr.x;
e.xconfigure.y = _xattr.y;
if(_reparented) {
e.xconfigure.x += _current_frame.origin.x;
e.xconfigure.y += _current_frame.origin.y;
}
e.xconfigure.width = _xattr.width;
e.xconfigure.height = _xattr.height;
e.xconfigure.border_width = _xattr.border_width;
e.xconfigure.above = _reparented ? _frame_id : _screen-_root;
e.xconfigure.override_redirect = False;
XSendEvent(x_dpy, _id, False, StructureNotifyMask, e);
}
---
When we process the ConfigureRequestEvent we send a ConfigureNotify to
the decoration/frame window using XConfigureWindow:
static void
x_event_configure_request (XConfigureRequestEvent *e)
{
x_window *w = x_get_window (e-window);
XWindowChanges client_changes, real_frame_changes, *frame_changes;
unsigned long client_mask, real_frame_mask, *frame_mask;
CGRect client_rect;
if (w != nil e-window != w-_id)
w = nil;
if (w == nil)
{
/* whatever.. */
client_changes.stack_mode = e-detail;
client_changes.sibling = e-above;
client_changes.x = e-x;
client_changes.y = e-y;
client_changes.width = e-width;
client_changes.height = e-height;
XConfigureWindow (x_dpy, e-window, e-value_mask,
client_changes);
return;
}
if (e-value_mask CWBorderWidth)
w-_xattr.border_width = e-border_width;
//[w update_shaped];
client_mask = real_frame_mask = 0;
frame_changes = w-_reparented ? real_frame_changes :
client_changes;
frame_mask = w-_reparented ? real_frame_mask : client_mask;
if (e-value_mask CWStackMode)
{
frame_changes-stack_mode = e-detail;
*frame_mask |= CWStackMode;
if (e-value_mask CWSibling)
{
frame_changes-sibling = e-above;
*frame_mask |= CWSibling;
}
}
client_rect = CGRectMake (w-_xattr.x, w-_xattr.y,
w-_xattr.width, w-_xattr.height);
if (e-value_mask CWX)
client_rect.origin.x = e-x;
if (e-value_mask CWY)
client_rect.origin.y = e-y;
if (e-value_mask CWWidth)
client_rect.size.width = e-width;
if (e-value_mask CWHeight)
client_rect.size.height = e-height;
[w resize_client:client_rect];
if (real_frame_mask != 0)
{
XConfigureWindow (x_dpy, w-_frame_id,
real_frame_mask, real_frame_changes);
}
if (client_mask != 0)
{
