[ANNOUNCE] xextproto 7.0.4
Peter Hutterer (4): Xge.h: include Xmd.h for CARD8 geproto: remote trailing whitespaces. Clean up XGE documentation. Bump to 7.0.4 git tag: xextproto-7.0.4 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.4.tar.bz2 MD5: 64c19cbf368f053cfc689609589dacfe xextproto-7.0.4.tar.bz2 SHA1: cb5d78633eb909f706cf5904910083471c53089d xextproto-7.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.4.tar.gz MD5: 0fc12ee44a2648aaefebcb37d854f18d xextproto-7.0.4.tar.gz SHA1: a18ad182e3d44bb81a4564d6c16187fb45ad1b0c xextproto-7.0.4.tar.gz pgpDqnY8sDjnE.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [PATCHES] improve gamma support for randr-1.2 drivers
On Dec 17, 08 16:43:00 +0100, Maarten Maathuis wrote: My main question is, are there any xserver ABI's to bump due to the changes to the xf86CrtcRec struct? Answering myself, no ABI bump is needed, because i only appended something to a structure, and multiple instances of that structure are not allocated as one chunk of memory. I suggest bumping XF86_CRTC_VERSION, so that drivers can validate crtc-version before using the new fields (if they want to, that is). Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[patch] xf86Crtc.c
Below is a patch that will allow xf86Crtc.c to compile if
RANDR_GET_CRTC_INTERFACE
is turned off. Only the first change is needed, the second one is
just to show where
the compile problem occurs.
I have not actually compiled this, I found the problem by readng the code...
Pat
---
*** a/xserver/hw/xfree86/xf86Crtc.c 2008-12-17 12:36:09.0 -0600
--- b/xserver/hw/xfree86/xf86Crtc.c 2008-12-17 12:41:07.0 -0600
***
*** 2524,2531
int c;
for (c = 0; c config-num_crtc; c++) {
- #if RANDR_GET_CRTC_INTERFACE
xf86CrtcPtr crtc = config-crtc[c];
xf86OutputPtr output = NULL;
uint32_tdesired_outputs = 0, current_outputs = 0;
int o;
--- 2524,2531
int c;
for (c = 0; c config-num_crtc; c++) {
xf86CrtcPtr crtc = config-crtc[c];
+ #if RANDR_GET_CRTC_INTERFACE
xf86OutputPtr output = NULL;
uint32_tdesired_outputs = 0, current_outputs = 0;
int o;
***
*** 2551,2557
!desired_outputs)
(*crtc-funcs-dpms)(crtc, DPMSModeOff);
#else
! (*crtc-funcs-dpms)(crtc, DPMSModeOff);
#endif
}
}
--- 2551,2557
!desired_outputs)
(*crtc-funcs-dpms)(crtc, DPMSModeOff);
#else
! (*crtc-funcs-dpms)(crtc, DPMSModeOff); /* crtc needed here -- PEK */
#endif
}
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: very bad, and very weird, scrolling text performance xorg 1.5.3 intel 2.5.1 GM965
On Sun, Dec 14, 2008 at 3:48 PM, Thomas Jaeger thjae...@gmail.com wrote: You really need the glyph cache in the X server to get decent text performance out of the 2.5 intel driver. The patches are pretty straightforward to backport, but it is my understanding that a 1.6 server will be uploaded to jaunty soon, so you might want to wait for that. I was skeptical, but the 1.6 xorg server was uploaded to Jaunty today and it's much faster, still using 2.5.1 intel driver. -jwb ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
On Wed, Dec 17, 2008 at 09:21:47PM +1100, Daniel Stone wrote: Hi, On Wed, Dec 17, 2008 at 12:02:34PM +0200, Marius Gedminas wrote: On Wed, Dec 17, 2008 at 12:04:16PM +1000, Peter Hutterer wrote: To send that key from an input driver you'd have to init the key class and send the keycode up to the DDX. But being 255 the server would ignore it. Are there any plans about dealing with keycodes 255? I keep noticing this problem in various contexts recently, and I'd like to know if * there's no known solution Not for core-only clients. Are workarounds (e.g. allowing users to remap keycodes 255 to keycodes 255) possible, or too ugly to be allowed to see daylight? * there's a solution, but nobody currently has the time to work on it * there's a solution and somebody is working on it Xi2/3 and XKB2 will take care of this problem, and they're targeted towards 1.7. Clients will need to use the Xi rather than core event API to get these events, though. And, presumably, that can be implemented inside toolkits. Marius Gedminas -- Favorite MAC error message: Not enough memory to eject disk! signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: mesa, intel driver, and synchronous flipping
On Wed, 2008-12-17 at 18:11 +1100, garrone wrote: The mesa direct rendering with the intel driver appears to rely on asychronous flipping. However the hardware, according to the 965 documentation I have downloaded from the intellinuxgraphics site, is capable of synchronous flips. (The kernel file i915_dma.c ors in the ASYNC_FLIP constant in the function i915_dispatch_flip, invoked eventually by a call to glXSwapBuffers. For a description of the hardware capability, refer to volume 1 of the 965 graphics pdf files, searching for the command MI_DISPLAY_FLIP) The application I am targeting has dual opengl windows, each one running on a separate display, and covering the whole of that display, from a single Intel graphics chipset. This was working with synchronous flips at some point at least on i915/i945 hardware, but I think the functionality has been ripped out again because GEM didn't mix well with it. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: specifying primary device
Beso wrote: 2008/12/17 Carl Karsten c...@personnelware.com: (!!) More than one possible primary device found google says to specify BusID, which I do. Is there a .conf setting to specify which it is? No clue if it will have any impact on anything, but it is in the log, so I figured I should follow it. do a lspci and identify your video device bus. then put BusID bus id in your device section in the xorg.conf. example; let's say that my video device has been identified on the 1:5:0 pci bus. i'd open my xorg.conf and put the following line in my device section. BusID 1:5:0 after that select that specific device in your screen section so that it can be used as default for that specific screen that is set as default in the serverlayout section. it influences the board you chose. according to man xorg.conf: BusID PCI:bus:device:function but it still gave me the warning # xorg.conf Section ServerLayout Identifier Layout0 # Screen dell1901fp 0 0 # screen pt810 screen dellM991 # screen pt810 RightOf dell1901fp # screen dellM991 above pt810 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer EndSection Section ServerFlags Option Xinerama 0 Option InitPrimary 1 EndSection Section Extensions Option Composite 1 EndSection Section DRI Mode0666 EndSection Section Monitor Identifier dell1901fp VendorName Dell ModelName DELL 1901FP HorizSync 30.0 - 80.0 VertRefresh 56.0 - 76.0 # Option DPMS EndSection Section Monitor # http://www.monitorworld.com/Monitors/viewsonic/viewsonicpt810.html # Max Resolution: 1600 x 1200 # Sync Type:Seperate # H Freq/ V Freq: 30-96 Khz / 50-160 Hz Identifier pt810 Vendorname ViewSonic # HorizSync 30-96 # VertRefresh 50-160 Option DPMS EndSection Section Monitor Identifier dellM991 Vendorname Dell Modelname Dell M991 # HorizSync 30-96 # VertRefresh 50-160 Option DPMS EndSection Section Device Identifier nv0 Driver nvidia # Driver vesa VendorName NVIDIA Corporation BoardName GeForce2 MX/MX 400 Busid PCI:1:0:0 Option NoLogo 0 Option NoInt10 1 EndSection Section Device # 02:08.0 VGA compatible controller: ATI Technologies Inc Rage 128 PP/PRO TMDS [Xpert 128] Identifier rage # Driver ati Driver r128 # Driver vesa # Driver fglrx Vendorname ATI Boardname ATI Rage 128 Busid PCI:2:8:0 Option UseFBDev 1 Option NoInt10 1 # Option MergedFB off # Option OldDmaInitTrue # Option DRI off EndSection Section Device # 02:09.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 03) Identifier mach # Driver ati Driver mach64 # Driver fglrx # Driver vesa Boardname Mach64 Busid PCI:2:9:0 Option probe_sparse 1 # Option OldDmaInit1 Option NoInt10 0 Option DRI 0 Option UseFBDev 1 Option MergedFB 0 EndSection Section Screen Identifier dell1901fp Monitordell1901fp Device nv0 DefaultDepth24 # Option metamodes 1280x1024_60 +0+0; 1280x1024 +0+0; 1024x768 +0+0; 800x600 +0+0; 640x480 +0+0 SubSection Display Depth 24 Modes 1280x1024x60 1024x768 EndSubSection EndSection Section Screen Identifier pt810 Monitor pt810 Device rage Defaultdepth24 SubSection Display Depth 24 Modes1024x768 # Modes1600x1200 1024x768 EndSubSection EndSection Section Screen Identifier dellM991 Monitor dellM991 Device mach Defaultdepth24 SubSection Display Depth 24 Modes1024x768 EndSubSection EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/psaux Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection X.Org X Server 1.5.2 Release Date: 10 October 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.24-19-server i686 Ubuntu Current Operating System: Linux dell29 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 Build Date: 24 October 2008 08:00:16AM xorg-server 2:1.5.2-2ubuntu3 (bui...@rothera.buildd) Before reporting problems,
Re: proto/randrproto: Branch 'master'
On Dec 16, 08 22:34:22 +0200, Fatih Aşıcı wrote: Salı 16 Aralık 2008 tarihinde, Matthias Hopf şunları yazmıştı: +#define RR_PROPERTY_SIGNAL_FORMAT SignalFormat +#define RR_PROPERTY_SIGNAL_FORMAT SignalProperties It looks like a copy/paste error? F*ck. Thanks. Apparently already fixed by Maarten. Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Include sdk header dependencies and protect agains't multiple inclusion.
Eric Anholt wrote: Hi, The attached patch is the result of as few extra inclusions as possible, by creating a dummy file including just that header, and making it compile. This was done in the loader directory, and I added some extra -I for module headers, but including in the build tree. This seems like a bunch of churn for something that's not actually broken. Sorry, did not understand that phrase, and google translation was not much helpful. But I feel you were not saying how much you loves me :-) The patch as a whole may not be required to apply, and not that patch verbatim, as it would require still at least a review to ensure every sdk header passes the: ifdef HAVE_FOO_CONFIG_H #include foo-config.h #endif when it is applicable. But always including it would not really be a problem, just that those bits are only required before installing the headers, i.e. in the X Server build. To apply a minimal amount of the patch, it would be required to just add the proper #ifndef FOO_H #define FOO_H file-contents #endif /* FOO_H */ to the headers that don't guard agains't multiple inclusion. And a more complete work is to only define in sdk headers those symbols that should not be available to drivers. Anyway, the current code is ok, and should require minimal maintenance work to compile the X Server and modules with hidden symbols by default (most of it is just changing a header instead of hunting symbols in the C sources, that have theirs names frequently generated after macro expansions...). Paulo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Include sdk header dependencies and protect agains't multiple inclusion.
On Wed, Dec 17, 2008 at 06:23:09PM -0200, Paulo César Pereira de Andrade wrote: The patch as a whole may not be required to apply, and not that patch verbatim, as it would require still at least a review to ensure every sdk header passes the: ifdef HAVE_FOO_CONFIG_H #include foo-config.h #endif It's failure-prone, and increases the amount of work for developers. I didn't see any figures on how much faster the build would be, to compensate for this. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpZRDy3rBUfs.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
On Wed, Dec 17, 2008 at 12:04:16PM +1000, Peter Hutterer wrote: Actually MS has defined standard Zoom+/Zoom- keycodes in the HID spec (before mouse wheel zooming took over MS thought a zoom lever in its ergo keyboards would be a great idea), so if they are not part of the 255 crowd xorg currently zaps commanding zoom function should just be a matter of sending those codes, and hoping zooming apps recognize them you're right, there's a key for it. from linux/input.h: #define KEY_ZOOMIN 0x1a2 #define KEY_ZOOMOUT 0x1a3 To send that key from an input driver you'd have to init the key class and send the keycode up to the DDX. But being 255 the server would ignore it. Are there any plans about dealing with keycodes 255? I keep noticing this problem in various contexts recently, and I'd like to know if * there's no known solution * there's a solution, but nobody currently has the time to work on it * there's a solution and somebody is working on it Marius Gedminas -- F U cn rd dis U mst uz Unix. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Let the DDX decide on the XkbRulesDefaults.
On Tue, Dec 16, 2008 at 11:28 PM, Daniel Stone dan...@fooishbar.org wrote: On Tue, Dec 16, 2008 at 11:04:15PM -0800, Dan Nicholson wrote: The other reason I had in mind was to tie into the keymap cache patch I sent. Smarter default means better chance you can reuse the cached map. And I definitely agree that the the XkbSetRulesDflts API is not exactly the way you'd envision things working. Would it be better at some point to have a new function where the driver just passes in the RMLVO it wants instead of setting new defaults and then passing in a (probably empty) XkbComponentNamesRec? Then the DDX could just set the defaults once instead of having them continually blown away. extern Bool InitKeyboardDeviceStruct( -DevicePtr /*device*/, -KeySymsPtr /*pKeySyms*/, -CARD8 /*pModifiers*/[], +DeviceIntPtr /*device*/, +XkbRMLVOSet * /*rmlvo*/, BellProcPtr /*bellProc*/, KbdCtrlProcPtr /*controlProc*/); It's a WIP. I see you're not too worried about breaking the ABI. :) I suppose kbd and evdev are the only two drivers that are actually going to call the *InitKeyboardDeviceStruct anyway and would be easy to fix. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multi head failsafe
On Wed, 17 Dec 2008, Carl Karsten wrote: I have 3 video cards: 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 02:08.0 VGA compatible controller: ATI Technologies Inc Rage 128 PP/PRO TMDS [Xpert 128] 02:09.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 03) I am pretty sure I had all 3 working at one point, then I did 'something' and lost one. last night I installed ubntu ibex and now I can only get the nvidia one to work. I use the extra monitors for IRC and doc files, so I don't need much in the way of graphics. What I am hoping for is something very basic and low end that will help me verify that cables are plugged in, boards are still working, etc. And in the future, help me and others troubleshoot. If it locks or doesn't run at that point, you're probably running into this bug: https://bugs.freedesktop.org/show_bug.cgi?id=18160 (I noticed your log finishes with initializing int10, which is what mine finished with when I ran into this bug). The cause is that, at a certain point, Xorg got rid of its inbuilt PCI handling code, and has been relying on the kernel PCI code. Unfortunately, there's been a bug in the Xorg code, and a bug in the kernel as well. Either Alex Villacis-Lasso (excuse lack of diacritics) will fix it, or my book on PCI architecture will arrive, and I'll give it a go myself (but it may be beyond me). The workaround is to downgrade to an older version of Xorg. I forget what version worked, but IIRC, it worked in Fedora 8, but not Fedora 9 (I went straight from Fedora 6 to Fedora 10 myself, so I'm unsure). HTH some. - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Include sdk header dependencies and protect agains't multiple inclusion.
On Wed, Dec 17, 2008 at 03:34:04PM -0500, Thomas Dickey wrote: On Wed, Dec 17, 2008 at 06:23:09PM -0200, Paulo C?sar Pereira de Andrade wrote: The patch as a whole may not be required to apply, and not that patch verbatim, as it would require still at least a review to ensure every sdk header passes the: ifdef HAVE_FOO_CONFIG_H #include foo-config.h #endif It's failure-prone, and increases the amount of work for developers. I didn't see any figures on how much faster the build would be, to compensate for this. With any non-braindead compiler, it is the same as just including the file with include guards. E.g. GCC knows about such include files and optimises the include away for any but the first time. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
Hi, On Wed, Dec 17, 2008 at 12:02:34PM +0200, Marius Gedminas wrote: On Wed, Dec 17, 2008 at 12:04:16PM +1000, Peter Hutterer wrote: To send that key from an input driver you'd have to init the key class and send the keycode up to the DDX. But being 255 the server would ignore it. Are there any plans about dealing with keycodes 255? I keep noticing this problem in various contexts recently, and I'd like to know if * there's no known solution Not for core-only clients. * there's a solution, but nobody currently has the time to work on it * there's a solution and somebody is working on it Xi2/3 and XKB2 will take care of this problem, and they're targeted towards 1.7. Clients will need to use the Xi rather than core event API to get these events, though. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: multi head failsafe
Timothy S. Nelson wrote: On Wed, 17 Dec 2008, Carl Karsten wrote: I have 3 video cards: 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) 02:08.0 VGA compatible controller: ATI Technologies Inc Rage 128 PP/PRO TMDS [Xpert 128] 02:09.0 VGA compatible controller: ATI Technologies Inc 210888GX [Mach64 GX] (rev 03) I am pretty sure I had all 3 working at one point, then I did 'something' and lost one. last night I installed ubntu ibex and now I can only get the nvidia one to work. I use the extra monitors for IRC and doc files, so I don't need much in the way of graphics. What I am hoping for is something very basic and low end that will help me verify that cables are plugged in, boards are still working, etc. And in the future, help me and others troubleshoot. If it locks or doesn't run at that point, you're probably running into this bug: https://bugs.freedesktop.org/show_bug.cgi?id=18160 (I noticed your log finishes with initializing int10, which is what mine finished with when I ran into this bug). The cause is that, at a certain point, Xorg got rid of its inbuilt PCI handling code, and has been relying on the kernel PCI code. Unfortunately, there's been a bug in the Xorg code, and a bug in the kernel as well. Either Alex Villacis-Lasso (excuse lack of diacritics) will fix it, or my book on PCI architecture will arrive, and I'll give it a go myself (but it may be beyond me). The workaround is to downgrade to an older version of Xorg. I forget what version worked, but IIRC, it worked in Fedora 8, but not Fedora 9 (I went straight from Fedora 6 to Fedora 10 myself, so I'm unsure). HTH some. This helps alot - I know to stop messing with my config and start downgradeing. thankyou very much. Carl K ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86SetGamma crashes the server [Re: xserver: Branch 'master']
I should swap the reply button for reply to all :-)
On 12/17/2008 10:50 PM, Maarten Maathuis wrote:
On 12/17/2008 09:33 PM, Aaron Plattner wrote:
On Wed, Dec 17, 2008 at 08:05:24AM -0800, Maarten Maathuis wrote:
hw/xfree86/common/Makefile.am |2
hw/xfree86/common/xf86Helper.c |6 +
hw/xfree86/common/xf86cmap.c |5 +
hw/xfree86/modes/xf86Crtc.c| 128
-
hw/xfree86/modes/xf86Crtc.h| 16 +
hw/xfree86/modes/xf86RandR12.c | 52
randr/randrstr.h | 12 +++
randr/rrcrtc.c | 35 ++-
8 files changed, 249 insertions(+), 7 deletions(-)
New commits:
commit 91f73b79b7ae64e5b846d1efeb470bb61a913720
Author: Maarten Maathuismadman2...@gmail.com
Date: Wed Dec 17 16:56:26 2008 +0100
randr: Improve per-crtc gamma support.
- The Gamma values from the monitor section are now used during
initial config.
- The old colormap system is disabled when gamma set hook is
available.
- Gamma values are now persistent for the lifetime of the xserver.
- This requires no driver changes and should be driver ABI
compatible.
I've got some changes pending, i'll add a check for non-NULL'ness of
xf86_config as well.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1c582006f0 (LWP 15464)]
0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0) at
/home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
3146for (c = 0; c xf86_config-num_crtc; c++) {
(gdb) bt
#0 0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0)
at /home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
#1 0x0045966b in xf86SetGamma (scrp=0x899ac0, gamma={red =
0, green = 0, blue = 0})
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Helper.c:925
#2 0x7f1c54264788 in VESAPreInit (pScrn=0x899ac0, flags=value
optimized out)
at /home/aaron/X/modular/driver/xf86-video-vesa/src/vesa.c:640
#3 0x00453ab8 in InitOutput (pScreenInfo=0x8702a0, argc=4,
argv=0x7fff60336308)
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Init.c:1007
#4 0x00428315 in main (argc=4, argv=0x7fff60336308,
envp=0x7fff60336330) at /home/aaron/X/modular/xserver/dix/main.c:308
(gdb) p xf86_config
$1 = (xf86CrtcConfigPtr) 0x21
(gdb) p xf86CrtcConfigPrivateIndex
$2 = -1
___
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
Docs in the modular tree, how to ?
Hi all, I've downloaded the modular tree using the git_xorg script, as described in the ModularDevelopersGuide wiki page. I see a 'doc' subdirectory, which I've tried to build, it installs a set of .sgml files, these seem to be some X.org docs that I'd like to read... what should I do with this ? I saw that there's also a xorg-sgml-doctools ? I'm going to be offline for some time (Xmas season :-), and I was hoping I could take some reading material with me, which is why the wiki docs is not what I'm looking for. Maybe there's a description somewhere of how to build an independent set of docs ? this would help. Thanks, Joao -- Joao Moreira de Sa Coutinho joao.more...@free.fr ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
On Wed, Dec 17, 2008 at 05:42:42PM +0200, Marius Gedminas wrote: On Wed, Dec 17, 2008 at 09:21:47PM +1100, Daniel Stone wrote: Hi, On Wed, Dec 17, 2008 at 12:02:34PM +0200, Marius Gedminas wrote: On Wed, Dec 17, 2008 at 12:04:16PM +1000, Peter Hutterer wrote: To send that key from an input driver you'd have to init the key class and send the keycode up to the DDX. But being 255 the server would ignore it. Are there any plans about dealing with keycodes 255? I keep noticing this problem in various contexts recently, and I'd like to know if * there's no known solution Not for core-only clients. Are workarounds (e.g. allowing users to remap keycodes 255 to keycodes 255) possible, or too ugly to be allowed to see daylight? the latter. You could get around it by assigning a 3 group xkb layout on the device and then - in the driver - switch the group before sending a keycode above 255. The theory then goes that for groups 3 and above you can do keycode % 255 and it'll be mapped to the correct thing. This however assumes that - the driver knows about xkb and manages the keymaps accordingly. which it doesnt. - the clients don't touch the xkb map for the device. which they do. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xfree86: don't restore the TTY mode if we didn't initialize it ourselves
Restoring it unconditionally means we restore to whatever tty_mode has as
default value (i.e. 0). K_RAW happens to be 0x00, so we always restore to raw
mode if allowEmptyInput is off.
---
hw/xfree86/os-support/linux/lnx_init.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_init.c
b/hw/xfree86/os-support/linux/lnx_init.c
index da5ca57..6ee8ed6 100644
--- a/hw/xfree86/os-support/linux/lnx_init.c
+++ b/hw/xfree86/os-support/linux/lnx_init.c
@@ -376,8 +376,10 @@ xf86CloseConsole()
xf86Msg(X_WARNING, xf86CloseConsole: KDSETMODE failed: %s\n,
strerror(errno));
-ioctl(xf86Info.consoleFd, KDSKBMODE, tty_mode);
-tcsetattr(xf86Info.consoleFd, TCSANOW, tty_attr);
+if (xf86Info.allowEmptyInput) {
+ ioctl(xf86Info.consoleFd, KDSKBMODE, tty_mode);
+ tcsetattr(xf86Info.consoleFd, TCSANOW, tty_attr);
+}
if (ioctl(xf86Info.consoleFd, VT_GETMODE, VT) 0)
xf86Msg(X_WARNING, xf86CloseConsole: VT_GETMODE failed: %s\n,
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 0/2] XIPropToInt and XIPropToFloat APIs
These two patches add two new APIs to the server. XIPropToInt - convert the given property into an integer array XIPropToFloat - convert the given property into an float array More importantly, the second patch also adds XATOM_FLOAT as a server-defined property that drivers can use to denote float properties (the synaptics driver is waiting for exactly that, and so is property support for pointer acceleration). Requirement for this to work is that both client and server store floats in IEEE 754 format and that the client stores float in the same byte ordering as everything else. Which - unless I misunderstood the material - is more than likely. I sent them to the list previously, since they have changed a bit to make the API more robust to abuse or mis-use. The code was originally written by Simon Thum. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 1/2] Xi: add XIPropToInt() auxiliary function.
From: Peter Hutterer peter.hutte...@redhat.com
Converts an XIPropertyValuePtr to an integer, provided that type and format is
right.
Code originally written by Simon Thum.
Signed-off-by: Peter Hutterer peter.hutte...@redhat.com
---
Xi/xiproperty.c| 68
include/exevents.h |6
2 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index e79a2ed..cd9805a 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -32,6 +32,7 @@
#include dix.h
#include inputstr.h
#include X11/extensions/XI.h
+#include X11/Xatom.h
#include X11/extensions/XIproto.h
#include exglobals.h
#include exevents.h
@@ -71,6 +72,73 @@ XIGetKnownProperty(char *name)
}
/**
+ * Convert the given property's value(s) into @nelem_return integer values and
+ * store them in @buf_return. If @nelem_return is larger than the number of
+ * values in the property, @nelem_return is set to the number of values in the
+ * property.
+ *
+ * If *...@buf_return is NULL and @nelem_return is 0, memory is allocated
+ * automatically and must be freed by the caller.
+ *
+ * Possible return codes.
+ * Success ... No error.
+ * BadMatch ... Wrong atom type, atom is not XA_INTEGER
+ * BadAlloc ... NULL passed as buffer and allocation failed.
+ * BadLength ... @buff is NULL but @nelem_return is non-zero.
+ *
+ * @param val The property value
+ * @param nelem_return The maximum number of elements to return.
+ * @param buf_return Pointer to an array of at least @nelem_return values.
+ * @return Success or the error code if an error occured.
+ */
+_X_EXPORT int
+XIPropToInt(XIPropertyValuePtr val, int *nelem_return, int **buf_return)
+{
+int i;
+int *buf;
+
+if (val-type != XA_INTEGER)
+return BadMatch;
+if (!*buf_return *nelem_return)
+return BadLength;
+
+switch(val-format)
+{
+case 8:
+case 16:
+case 32:
+break;
+default:
+return BadValue;
+}
+
+buf = *buf_return;
+
+if (!buf !(*nelem_return))
+{
+buf = xcalloc(val-size, sizeof(int));
+if (!buf)
+return BadAlloc;
+*buf_return = buf;
+*nelem_return = val-size;
+} else if (val-size *nelem_return)
+*nelem_return = val-size;
+
+for (i = 0; i val-size i *nelem_return; i++)
+{
+switch(val-format)
+{
+case 8: buf[i] = ((CARD8*)val-data)[i]; break;
+case 16: buf[i] = ((CARD16*)val-data)[i]; break;
+case 32: buf[i] = ((CARD32*)val-data)[i]; break;
+}
+}
+
+return Success;
+}
+
+
+/**
* Init those properties that are allocated by the server and most likely used
* by the DIX or the DDX.
*/
diff --git a/include/exevents.h b/include/exevents.h
index 2a7ec97..485347b 100644
--- a/include/exevents.h
+++ b/include/exevents.h
@@ -251,4 +251,10 @@ extern _X_EXPORT Atom XIGetKnownProperty(
extern _X_EXPORT DeviceIntPtr XIGetDevice(xEvent *ev);
+extern _X_EXPORT int XIPropToInt(
+XIPropertyValuePtr val,
+int *nelem_return,
+int **buf_return
+);
+
#endif /* EXEVENTS_H */
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xinit 1.1.1
This is mainly just a bunch of updates for OSX Tiger compatability and SnowLeopard fratures. Alan Coopersmith (1): Fix build of startx xinitrc with Solaris make Jeremy Huddleston (17): Apple: privleged_startx: Increase the timeout so slower machines don't get a stray process warning in their system log. startx.cpp: Made some things a little more friendly for people who have spaces in pathnames. Apple: Using eval to protect people who have spaces in their home path. Support the instant-off API in SnowLeopard. Apple: sleep() to avoid innocent error message spew Apple: Make VPATH builds work on darwin Apple: Use AvailabilityMacros.h for Tiger compatability OSX: Create privleged_startx on Tiger OSX Tiger: More compilation fixes... OSX Tiger: Hopefully the last fix for Tiger users... Apple: Honor X11_PREFS_DOMAIN if it's set (1.4.2-apple26 and later) OSX Tiger: Fix discovery of mach port OSX: Fixed bad prefix OSX: More prefix fixes OSX: Don't use login/bash -c hack anymore for org.x.startx LaunchAgent Apple: Allow defaults option that maps to a -dpi server command line in startx xinit 1.1.1 git tag: xinit-1.1.1 http://xorg.freedesktop.org/archive/individual/app/xinit-1.1.1.tar.bz2 MD5: 93c73705ed9eb1e1a6b6938405672f2b xinit-1.1.1.tar.bz2 SHA1: 577a111efc9b5a8ec6cc294ae7c35048eebde704 xinit-1.1.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinit-1.1.1.tar.gz MD5: 3f1658343289f48a60c72d7019d547c8 xinit-1.1.1.tar.gz SHA1: 2a47b990c1b3c619f5c191d755f01d06e49abdf7 xinit-1.1.1.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xextproto 7.0.4
Peter Hutterer (4): Xge.h: include Xmd.h for CARD8 geproto: remote trailing whitespaces. Clean up XGE documentation. Bump to 7.0.4 git tag: xextproto-7.0.4 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.4.tar.bz2 MD5: 64c19cbf368f053cfc689609589dacfe xextproto-7.0.4.tar.bz2 SHA1: cb5d78633eb909f706cf5904910083471c53089d xextproto-7.0.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/xextproto-7.0.4.tar.gz MD5: 0fc12ee44a2648aaefebcb37d854f18d xextproto-7.0.4.tar.gz SHA1: a18ad182e3d44bb81a4564d6c16187fb45ad1b0c xextproto-7.0.4.tar.gz pgpdRZ5zemHhZ.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 0/2] XIPropToInt and XIPropToFloat APIs
Peter Hutterer wrote:
These two patches add two new APIs to the server.
XIPropToInt - convert the given property into an integer array
XIPropToFloat - convert the given property into an float array
More importantly, the second patch also adds XATOM_FLOAT as a server-defined
property that drivers can use to denote float properties (the synaptics driver
is waiting for exactly that, and so is property support for pointer
acceleration).
Requirement for this to work is that both client and server store floats in
IEEE 754 format and that the client stores float in the same byte ordering as
everything else. Which - unless I misunderstood the material - is more than
likely.
Erm... I strongly suggest not trying that. This quickly runs into a vey
special hell where each platform interprets IEEE754-1985 in it's own
subtle way (IEEE754-2008 will clean this partially up but it will take
some years until we see support for this). In the best case it works, in
the worst case you'll get corrupt data, differenly sized float types or
a SIGFPE (for example some platforms have nasty behaviour for payloads
within NaN values) ...
... I suggest to follow C99/XPG6 in this case which defines a new format
option for |printf()|/|scanf()| called %a which provides a portable
hexadecimal floating-point (hexfloat) representation which is portable
across all platforms, independent of endian/float encodings and
_guranteed_ to return the same output value for the serialied input
value (e.g. no rounding errors caused by base2---base10---base2
conversion).
Example:
-- snip --
#include stdlib.h
#include stdio.h
#include math.h
int main(int ac, char *av[])
{
char buff[256];
double x=1.1,
y=0.0;
sprintf(buff, %a, x);
printf(buff contains '%s'\n, buff);
y=atof(buff);
printf(ycontains '%g'\n, y);
return EXIT_SUCCESS;
}
-- snip --
... should print:
-- snip --
buff contains '0x1.1999ap+0'
ycontains '1.1'
-- snip --
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.ma...@nrubsig.org
\__\/\/__/ MPEG specialist, CJAVASunUnix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
