[ANNOUNCE] mkfontscale 1.0.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (6): Add support for bzip2 compressed fonts if configured --with-bzip2 Use XORG_CWARNFLAGS XORG_CHANGELOG from xorg-macros 1.2 Add basic README with URL's of git, bugzilla mailing list Add hooks for checking sources with lint/sparse/etc. man page typo fix Version 1.0.6 git tag: mkfontscale-1.0.6 http://xorg.freedesktop.org/archive/individual/app/mkfontscale-1.0.6.tar.bz2 MD5: 0d0752af232054b720febcc1b2fd6c57 SHA1: 7bb7caa5a365d1e31a25ed9e837ca744aaa83db0 http://xorg.freedesktop.org/archive/individual/app/mkfontscale-1.0.6.tar.gz MD5: 721293d4b82f04cf15f822ab7c664af6 SHA1: 8811fbda3101733a6e527e6ecf55f8ff1e93a2e1 - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJSvn5ovueCB8tEw4RAhBVAJ9T6oav2rt0pFdzwrJznnZCm2EROACeKoUB 4XyTCsbJLteHQQT2JNJ8oXQ= =ssAN -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [RFC] RandR 1.3 properties, version 2
Matthias Hopf wrote: AFAIR we agreed on that this property name can just be changed without breaking backward compatibility, because it was never agreed upon that this was a standard so far. I guess I can always add yet another EDID atom string check to my display color profile management code, but is there a reason to change it ? (I use the EDID in an attempt to uniquely associate a display color profile with a display monitor instance, so that it's possible for the profile to follow the display even when it's plugged into a different output, or different monitors are being used at different times.) Graeme Gill. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Zoom Support
On Thu, Dec 18, 2008 at 08:58:08AM +1000, Peter Hutterer wrote: On Wed, Dec 17, 2008 at 05:42:42PM +0200, Marius Gedminas wrote: 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. I was thinking more of the driver swapping around keycodes before XKB ever gets to see them. My laptop's keyboard has less than a hundred keys, and it's a bit weird not to have one of them (ThinkVantage) available for binding to global desktop actions (Lock Screen -- this was a bit funnier in older thinkpads, where that key was labelled 'Access IBM') because all the other keycodes under 255 are reserved for keys I don't actually have. I realize, though, that having an extra layer of configuration in the already messy world of input devices is not something X developers would welcome with open arms. ;-) 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: image corruption when in multiseat mode and vga!=normal kernel parameter
Tomasz Chmielewski schrieb: I have a multiseat system with one AGP card (nvidia GeForce FX 5200; primary card, BIOS displays here) and one PCI card (ATI), running Linux. If I start X in multiseat mode (X on both cards, two keyboards+mice), image is corrupted on nvidia AGP card: The corruption happens with nv, nouveau and binary nvidia driver and a vga= mode different than normal (i.e. vga=791). The corruption does _not_ happen when I don't use vga= parameter (or use vga=normal). The corruption does not happen if I start X only on one of the cards. I replaced the nvidia AGP card for an ATI card and I can see the same corruption. So it doesn't seem to be related to the graphics card or the driver, but some strange issue between the X server and Linux framebuffer? -- Tomasz Chmielewski http://wpkg.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties, version 2
On Dec 18, 08 18:34:26 +1100, Graeme Gill wrote: Matthias Hopf wrote: AFAIR we agreed on that this property name can just be changed without breaking backward compatibility, because it was never agreed upon that this was a standard so far. I guess I can always add yet another EDID atom string check to my display color profile management code, but is there a reason to change it ? It conforms to the standard naming scheme we AFAIU agreed on on the mailing list. I'd have no issues with adding a non-advocated EDID_DATA again to the server, if that sounds fit reasonable. Keith? 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: [PATCHES] improve gamma support for randr-1.2 drivers
On Dec 17, 08 21:38:50 +0100, Maarten Maathuis wrote: Will do, as part of some more fixes. Anything else than happens to be on your mind while I'm breaking abi? Nope, not from my side. Is this supposed to get into 1.6 still, or just in master? 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: [RFC] RandR 1.3 properties, version 2
On Thu, 2008-12-18 at 14:41 +0100, Matthias Hopf wrote: I guess I can always add yet another EDID atom string check to my display color profile management code, but is there a reason to change it ? Yeah, adopting a consistent standard property set will help applications in the future as drivers start exposing the standard names. I'd have no issues with adding a non-advocated EDID_DATA again to the server, if that sounds fit reasonable. Keith? I'd not encourage non-standard property names for things which we have standard properties for, that only encourages confusion. -- keith.pack...@intel.com 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: X12 [wasRe: Zoom Support]
On Thu, Dec 18, 2008 at 02:51:52PM +0100, Nicolas Mailhot wrote: I hope that when XI and XKB are reworked a language property will be added to the protocol. Right now many apps try to infer the language being written from the xkb layout in use (for on the fly spellchecking, activation of the correct locl font features, etc) and since the same layout can be used to write different languages the heuristic breaks badly. MS got it write when they made layout and language two different properties apps could query. Ehm, you could do it as a per-window property (just walk up the tree until you find one, be it on a subwindow, the top-level app window, or the default on the root window), but it's nothing the X server knows about; strictly a client issue. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X12
Nicolas Mailhot nicolas.mail...@laposte.net writes: Hi, I hope that when XI and XKB are reworked a language property will be added to the protocol. Right now many apps try to infer the language being written from the xkb layout in use (for on the fly spellchecking, activation of the correct locl font features, etc) and since the same layout can be used to write different languages the heuristic breaks badly. In which cases should this differ from the system locale? (I.e. whatever setlocale() returns). eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Don't treat PIXMAN_TYPE_YUY2 and PIXMAN_TYPE_YV12 as PIXMAN_FORMAT_COLOR.
Aaron Plattner aplatt...@nvidia.com writes: Various pieces of code expect PIXMAN_FORMAT_COLOR (and its less cool older brother, PICT_FORMAT_COLOR) formats to have ARGB bits, and the YUV formats do not. Looks good to me. Soren ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCHES] improve gamma support for randr-1.2 drivers
On Thu, 2008-12-18 at 17:55 +0100, Matthias Hopf wrote: Keith is the release manager, he will have the last word. CC'ing him. The 1.6 feature set is fixed at this point, so the gamma changes will need to wait for 1.7. -- keith.pack...@intel.com 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: X12 [wasRe: Zoom Support]
On Thu, Dec 18, 2008 at 06:02:33PM +0100, Nicolas Mailhot wrote: Layout and language are closely related. Basically for a globalized user that types in multiple languages, you have two situations : 1. If his current layout is sufficient for the other language, he will perform a language shift but keep the layout 2. Otherwise he will perform a simultaneous language+layout shift So both are dynamic properties that have similar change triggers and will probably be controlled by the same desktop bit of code (and similarly most apps which will want the status of one of them will also want the status of the other) I'm a globalized user that types in 4 languages or so. I have one common layout for all of them, which is a US qwerty with Multi_key and Kanji keys added. In my experience language choice for input is never at the whole desktop level but at the window or even more often logical subwindow level (file in xemacs, tab in firefox for wikis...). I expect such a language change to stay fixed in the logical subwindow context I do it in. I don't want a switch to english in my grant proposal edition window acts on the mail writing I'm doing with the french colleagues I'm communicating with about it. OTOH, if I was doing layout switches, I suspect I'd hate having it change with the focus. Keyboard layout is semantically linked with the keyboard, so moving the mouse (focus-follow-mouse) and possibly clicking in a window has nothing to do with the keyboard, so shouldn't change the layout (except if what you click on is a change kb layout icon/button obviously). I really think that in terms of mental model, layout changes and input language changes usually don't have the same scope, and the X server and X protocol are at the wrong level for the language changes but at the correct level for keyboard layout changes (under client-side control obviously). OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xfree86: don't restore the TTY mode if we didn't initialize it ourselves
On Thu, Dec 18, 2008 at 09:01:27 +1000, Peter Hutterer wrote: 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. Signed-off-by: Julien Cristau jcris...@debian.org Thanks, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
randr: panning doesn't change screen size
At least the xinerama sizes are not updated to reflect the size of the panned area. Meaning that your window manager won't consider the entire panned area as useable space. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Modeline autoadjusting problem
Hi, I'm currently trying to force a custom modeline using the intel driver version 2.5.0. I used the LVDSFixedMode false option to force the driver to skip any hardcoded/BIOS related modeline. Looking at the screen, I can definitely see that the modeline isn't taken into account (pixel are flicking, etc.). Looking further in the Xorg.log file I saw the following message: (II) intel(0): Mode for pipe B: (II) intel(0): Modeline 1024x600_g3x59.8 51.00 1024 1184 1185 1344 600 612 613 635 -hsync (37.9 kHz) (II) intel(0): Adjusted mode for pipe B: (II) intel(0): Modeline 1024x600_g3x59.8 65.00 1024 1048 1184 1344 768 771 777 806 -hsync (48.4 kHz) (II) intel(0): chosen: dotclock 65142 vco 1824000 ((m 76, m1 11, m2 9), n 2, (p 28, p1 2, p2 14)) (II) intel(0): Selecting less common 24 bit TMDS pixel format. Seems like the modeline is adjusted by the driver _even_ if I specified the LVDSFixedMode false option. I really don't know what to do next... How can I force my modeline to the driver? The panel I'm trying the configure has a native 1024x600 resolution and doesn't have any ROM for EDID info. Regards, Marc ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Modeline autoadjusting problem
On Thu, Dec 18, 2008 at 03:47:23PM -0500, Marc Ferland wrote: Seems like the modeline is adjusted by the driver _even_ if I specified the LVDSFixedMode false option. I really don't know what to do next... How can I force my modeline to the driver? You can't. Looking at the code, there is no way to tell the system you know what you're doing. -mode_fixup is called unconditionally, and i830_lvds_mode_fixup has no toggle to switch itself off. That mode fixup function takes lvds_fixed_mode as gospel, and seems to do part of the chipset programming, so you can't just disable it anyway. Strange. lvds_fixed_mode itself can only come from bios or ddc, not config from what I can see. It's weird there isn't a generic high level way to tell X not to trust the roms and trust the config instead, when it comes to modelines, dpi, things like that. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: load module problem with X.Org X Server 1.6.99.1
On Thu, 2008-12-18 at 20:04 +0100, Florian Lier wrote: Hello everybody, during the last few days I tried to run the modular xserver from the git, because I wanted to try Xi 2.0 - I complied X with the tiny little script which can be found here: http://www.x.org/wiki/Development/git During the last weeks everything worked well. Since today I get the following errors when I try to start the freshly compiled Xserver from git. (I exactly followed the instructions @wiki/development/git) (II) Loading /home/fl0/mpx2/lib/xorg/modules/extensions//libextmod.so dlopen: /home/fl0/mpx2/lib/xorg/modules/extensions//libextmod.so: undefined symbol: XvMCScreenInitProc (EE) Failed to load /home/fl0/mpx2/lib/xorg/modules/extensions//libextmod.so (II) UnloadModule: extmod (EE) Failed to load module extmod (loader failed, 7) (II) Loading /home/fl0/mpx2/lib/xorg/modules/extensions//libdri.so dlopen: /home/fl0/mpx2/lib/xorg/modules/extensions//libdri.so: undefined symbol: xf86LoadKernelModule (EE) Failed to load /home/fl0/mpx2/lib/xorg/modules/extensions//libdri.so (II) UnloadModule: dri (EE) Failed to load module dri (loader failed, 7) (II) LoadModule: nv (II) Loading /home/fl0/mpx2/lib/xorg/modules/drivers//nv_drv.so dlopen: /home/fl0/mpx2/lib/xorg/modules/drivers//nv_drv.so: undefined symbol: miPolyPoint (EE) Failed to load /home/fl0/mpx2/lib/xorg/modules/drivers//nv_drv.so (II) UnloadModule: nv (EE) Failed to load module nv (loader failed, 7) Is there anybody who can help me with that? cheers, Florian Wild guess you are on ubuntu ? If so install gawk, make distclean in xserver and rerun autogen.sh before rebuilding. Cheers, Jerome Glisse ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X.org crashes on current branches
2008/12/18 Tobias Hain tobias.h...@gmx.de: Hello, chipset: GM965 kernel: (vanilla) 2.6.28-rc8, (drm-intel-next) of Eric's 2.6.28-rc8 xserver: server-1.6-branch libdrm: master mesa: master and intel-2008-q4 xf86-video-intel: xf86-video-intel-2.6-branch remaining components: Kubuntu 8.10 I'm facing X.org crashes when launching X with all of the above: Backtrace: 0: /opt/gfx-test/bin/Xorg(xorg_backtrace+0x3b) [0x81323fb] 1: /opt/gfx-test/bin/Xorg(xf86SigHandler+0x51) [0x80b82a1] 2: [0xb7f9b400] 3: /opt/gfx-test/lib/dri/i965_dri.so [0xa75c6a08] 4: /opt/gfx-test/lib/dri/i965_dri.so(intelTexImage2D+0x7e) [0xa75c712e] 5: /opt/gfx-test/lib/dri/i965_dri.so(_mesa_TexImage2D+0x2aa) [0xa76647ea] 6: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a40278] 7: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6a5fb] 8: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6eb8a] 9: /opt/gfx-test/bin/Xorg(Dispatch+0x33f) [0x808cc6f] 10: /opt/gfx-test/bin/Xorg(main+0x3bd) [0x807192d] 11: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7ad3685] 12: /opt/gfx-test/bin/Xorg [0x8070de1] Fatal server error: Caught signal 11. Server aborting It's always the same crash and related to 3D compositing manager loading I guess. I tried some permutations of the above branches, but none worked. Always the same crash that I didn't have before updating the branches. I've been tracking intel driver development for a while, but not on a regular basis. I think I updated branches one month old and before that everything worked fine. xorg.conf doesn't contain anything special. It's KDE 4.1 compositing manager. Haven't tried anything else yet. Hope it sounds familiar to some. do the drm and intel module load at x startup? i has some similar messages some time ago on radeon caused by modules not autoloading at x startup. i've added them to autoload at startup and then it worked. for some reason after the 1.5 release i couldn't start x without them forcedly loaded by the kernel. try loading the modules manually and see if something changes. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Building latest Intel support for 945G
Folks, I am tantalisingly close to finding the problem I've got with the Xorg that I've built but I just need one little pointer in the right direction. In my previous post I found that some functions in Xorg were not being found by driver modules trying to be linked in. In the example in the previous post one such function was xf86LoadKernelModule and another example shown in Xorg.0.log was a miPolyRectangle() function. So I went grep'ing and nm'img about until I could find out where these were missing from. In the end I found that the Xorg I built in Vmware (and that worked) had these things listed in the output of nm Xorg but the one I built on the target system didn't have them. Yet I found the miPolyRectangle in the libmi.a that had been built on both systems. So there was something preventing libmi.a getting linked in during the build of Xorg. Finally I compared the xserver/config.log on both systems and the difference there that explains why one works and one doesn't is: XWIN_LIBS='$(top_builddir)/fb/libfb.la $(top_builddir)/Xext/libXext.la $(top_builddir)/config/libconfig.la $(top_builddir)/Xi/libXi.la $(top_builddir)/xkb/libxkb.la $(top_builddir)/xkb/libxkbstubs.la $(top_builddir)/composite/libcomposite.la $(top_builddir)/damageext/libdamageext.la ' (which works) Versus XWIN_LIBS='$(top_builddir)/fb/libfb.la $(top_builddir)/mi/libmi.la $(top_builddir)/xfixes/libxfixes.la $(top_builddir)/Xext/libXext.la $(top_builddir)/config/libconfig.la $(top_builddir)/randr/librandr.la $(top_builddir)/render/librender.la $(top_builddir)/dbe/libdbe.la $(top_builddir)/glx/libglx.la $(top_builddir)/xkb/libxkb.la $(top_builddir)/xkb/libxkbstubs.la $(top_builddir)/composite/libcomposite.la $(top_builddir)/damageext/libdamageext.la $(top_builddir)/miext/damage/libdamage.la $(top_builddir)/miext/shadow/libshadow.la $(top_builddir)/Xi/libXi.la $(top_builddir)/os/libos.la' (which does not work) libmi appears in the second but not the first and something about this causes it not to be linked into the final Xorg that is built. So what causes something to be listed or not listed on this line created by autogen.sh in the xserver directory? Presumably the autogen is finding something different between the two setups - but what? Cliff From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Cliff Lawson Sent: 18 December 2008 17:59 To: xorg@lists.freedesktop.org Subject: RE: Building latest Intel support for 945G But then the first sign of trouble is: (II) LoadModule: dri (II) Loading /root/X/lib/xorg/modules/extensions//libdri.so dlopen: /root/X/lib/xorg/modules/extensions//libdri.so: undefined symbol: xf86LoadKernelModule (EE) Failed to load /root/X/lib/xorg/modules/extensions//libdri.so (II) UnloadModule: dri (EE) Failed to load module dri (loader failed, 7) So the problem appears to be the fact that this is trying to link to xf86LoadKernelModule() that does not exist. So which bit of the jigsaw is it that should be providing this and which I must, therefore, have not got up to date yet? Cliff Lawson Scanned by MailDefender - managed email security from intY - www.maildefender.net Scanned by MailDefender - managed email security from intY - www.maildefender.net No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 17/12/2008 19:21 Scanned by MailDefender - managed email security from intY - www.maildefender.net Scanned by MailDefender - managed email security from intY - www.maildefender.net No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 17/12/2008 19:21 Scanned by MailDefender - managed email security from intY - www.maildefender.net___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: load module problem with X.Org X Server 1.6.99.1
On Thu, Dec 18, 2008 at 2:32 PM, Cliff Lawson cl...@amshold.com wrote: -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Jerome Glisse Sent: 18 December 2008 22:02 To: Florian Lier Wild guess you are on ubuntu ? If so install gawk, make distclean in xserver and rerun autogen.sh before rebuilding. Cheers, Jerome Glisse I think you may have also just solved the problem I just posted about (which is basically the same as this one). On a system where things worked the config.log said it had found gawk but on the system where it failed it said it had found mawk instead. It's a bit sad if it continues to build using mawk if this is known to cause a build fault. I think Paulo was trying to fix up the script so it would work with any POSIX awk. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: load module problem with X.Org X Server 1.6.99.1
Well that's a large round of virtual beers to Jerome!! The mawk/gawk thing WAS indeed the solution to getting me a working Xorg! :-) (sadly glxgears now looks worse than ever but that could be an xorg.conf thing - but that's a job for another day) Cliff -Original Message- From: Dan Nicholson [mailto:dbn.li...@gmail.com] Sent: 18 December 2008 22:42 To: Cliff Lawson Cc: xorg@lists.freedesktop.org Subject: Re: load module problem with X.Org X Server 1.6.99.1 On Thu, Dec 18, 2008 at 2:32 PM, Cliff Lawson cl...@amshold.com wrote: -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Jerome Glisse Sent: 18 December 2008 22:02 To: Florian Lier Wild guess you are on ubuntu ? If so install gawk, make distclean in xserver and rerun autogen.sh before rebuilding. Cheers, Jerome Glisse I think you may have also just solved the problem I just posted about (which is basically the same as this one). On a system where things worked the config.log said it had found gawk but on the system where it failed it said it had found mawk instead. It's a bit sad if it continues to build using mawk if this is known to cause a build fault. I think Paulo was trying to fix up the script so it would work with any POSIX awk. -- Dan Scanned by MailDefender - managed email security from intY - www.maildefender.net No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.9.18/1850 - Release Date: 17/12/2008 19:21 Scanned by MailDefender - managed email security from intY - www.maildefender.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XInput2 MD without SD again
On Thu, Dec 18, 2008 at 07:36:01PM +0100, Christian Beier wrote:
On Wed, 17 Dec 2008 12:14:22 +1000
Peter Hutterer peter.hutte...@who-t.net wrote:
On Tue, Dec 16, 2008 at 05:16:19PM +0100, Christian Beier wrote:
Oh and well, while we're at it: adding more than 6 or 7 MDs crashes the
Xserver. Try 'xinput create-master foo' six or more times. I think I'll
file another bug...
crash the server or FatalError it? I just tried it in here and it works
fine.
Do you have d507f60689f4e14383b0d24e63afc8cf836360d5 xfree86: don't
FatalError
on too many input devices?
Yep, I have that. I use an Xorg build from 15. December 2008.
Funny thing is, i wanted to reproduce the bug, and i could create MDs
up to id 19, then xinput bailed out with a BadAlloc error. Seems
everything was working. _But_ then I added another mouse to the laptop
and tried creating MDs up to the limit again, and voila: Got a Fatal
server error...
thanks. The trigger is that the poiner creation succeeds, but the keyboard
creation in fails. The server then tries to remove the pointer device which
segfaults. The patch below fixes this.
Cheers,
Peter
From 317120a3f18bd060c1744b0cdf27067386ea5cf2 Mon Sep 17 00:00:00 2001
From: Peter Hutterer peter.hutte...@who-t.net
Date: Fri, 19 Dec 2008 08:56:35 +1000
Subject: [PATCH] dix: don't disable uninitialized devices.
If a device hasn't been initialized, it doesn't have a cursor yet. So don't
set the cursor to the NullCursor, and don't try to DisableDevice either.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
dix/devices.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index 48b6e7d..ff6f0ec 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -965,11 +965,15 @@ RemoveDevice(DeviceIntPtr dev)
return BadImplementation;
initialized = dev-inited;
-if (DevHasCursor(dev))
-screen-DisplayCursor(dev, screen, NullCursor);
-
deviceid = dev-id;
-DisableDevice(dev);
+
+if (initialized)
+{
+if (DevHasCursor(dev))
+screen-DisplayCursor(dev, screen, NullCursor);
+
+DisableDevice(dev);
+}
prev = NULL;
for (tmp = inputInfo.devices; tmp; (prev = tmp), (tmp = next)) {
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] mkfontscale 1.0.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (6): Add support for bzip2 compressed fonts if configured --with-bzip2 Use XORG_CWARNFLAGS XORG_CHANGELOG from xorg-macros 1.2 Add basic README with URL's of git, bugzilla mailing list Add hooks for checking sources with lint/sparse/etc. man page typo fix Version 1.0.6 git tag: mkfontscale-1.0.6 http://xorg.freedesktop.org/archive/individual/app/mkfontscale-1.0.6.tar.bz2 MD5: 0d0752af232054b720febcc1b2fd6c57 SHA1: 7bb7caa5a365d1e31a25ed9e837ca744aaa83db0 http://xorg.freedesktop.org/archive/individual/app/mkfontscale-1.0.6.tar.gz MD5: 721293d4b82f04cf15f822ab7c664af6 SHA1: 8811fbda3101733a6e527e6ecf55f8ff1e93a2e1 - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJSvn5ovueCB8tEw4RAhBVAJ9T6oav2rt0pFdzwrJznnZCm2EROACeKoUB 4XyTCsbJLteHQQT2JNJ8oXQ= =ssAN -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties, version 2
Matthias Hopf wrote: I have just pushed a change to radeonhd, that implements the mandatory bits of RandR 1.3 output properties, which can thus be seen as a reference implementation. Sorry I guess I'm not following very well :- so this means that the XRandR EDID_DATA atom now becomes what ? RANDR_EDID_DATA ? _EDID_DATA ? _RANDR_EDID_DATA ? thanks, Graeme Gill. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] dix: re-implement enter/leave model.
The old model was implemented based on a misunderstanding of NotifyVirtual and NotifyNonlinearVirtual events. It became complicated and was broken in some places [1]. This patch wipes this model completely. A much simplified implementation is provided instead. Rather than a top-down approach (we have a tree of windows, which ones need to get which event) this one uses a step-by-step approach. For each window W between A and B determine the pointer window P as perceived by this window and determine the event type based on this information. This is in-line with the model described by Owen Taylor [2]. [1] http://lists.freedesktop.org/archives/xorg/2008-December/041559.html [2] http://lists.freedesktop.org/archives/xorg/2008-August/037606.html --- Since this patch is rather hard to review, the new enterleave.c file is available on http://people.freedesktop.org/~whot/patches/enterleave.c It's probably easier to just look at this file. I've tested it with one and two mice and have yet to trip it up. There's cleanup patches following this one but one of these is pending the implementation of the focus in/out model. And NotifyPointer is giving me the creeps. dix/enterleave.c | 593 +- 1 files changed, 315 insertions(+), 278 deletions(-) diff --git a/dix/enterleave.c b/dix/enterleave.c index 8176f96..2a674ca 100644 --- a/dix/enterleave.c +++ b/dix/enterleave.c @@ -42,71 +42,17 @@ * For a full description of the model from a window's perspective, see * http://lists.freedesktop.org/archives/xorg/2008-August/037606.html * + * Additional notes: + * The core protocol spec says that In a LeaveNotify event, if a child of the + * event window contains the initial position of the pointer, then the child + * component is set to that child. Otherwise, it is None. For an EnterNotify + * event, if a child of the event window contains the final pointer position, + * then the child component is set to that child. Otherwise, it is None. * - * EnterNotify(Virtual, B) means EnterNotify Event, detail Virtual, child = B. - * - * Pointer moves from A to B, nonlinear (CoreEnterLeaveNonLinear): - * 1. a. if A has another pointer, goto 2. - *b. otherwise, if A has a child with a pointer in it, - * LeaveNotify(Inferior) to A - * LeaveNotify(Virtual) between A and child(A) - * - * 2. Find common ancestor X between A and B. - * 3. Find closest pointer window P between A and X. - *a. if P exists - * LeaveNotify(Ancestor) to A - * LeaveNotify(Virtual) between A and P - *b. otherwise, if P does not exist, - * LeaveNotify(NonLinear) to A - * LeaveNotify(NonLinearVirtual) between A and X. - * - * 4. If X does not have a pointer, EnterNotify(NonLinearVirtual, B) to X. - * 5. Find closest pointer window P between X and B. - *a. if P exists, EnterNotify(NonLinearVirtual) between X and P - *b. otherwise, EnterNotify(NonLinearVirtual) between X and B - * - * 5. a. if B has another pointer in it, finish. - *b. otherwise, if B has a child with a pointer in it - * LeaveNotify(Virtual) between child(B) and B. - * EnterNotify(Inferior) to B. - *c. otherwise, EnterNotify(NonLinear) to B. - * - * -- - * - * Pointer moves from A to B, A is a parent of B (CoreEnterLeaveToDescendant): - * 1. a. If A has another pointer, goto 2. - *b. Otherwise, LeaveNotify(Inferior) to A. - * - * 2. Find highest window X that has a pointer child that is not a child of B. - *a. if X exists, EnterNotify(Virtual, B) between A and X, - * EnterNotify(Virtual, B) to X (if X has no pointer). - *b. otherwise, EnterNotify(Virtual, B) between A and B. - * - * 3. a. if B has another pointer, finish - *b. otherwise, if B has a child with a pointer in it, - * LeaveNotify(Virtual, child(B)) between child(B) and B. - * EnterNotify(Inferior, child(B)) to B. - *c. otherwise, EnterNotify(Ancestor) to B. - * - * -- - * - * Pointer moves from A to B, A is a child of B (CoreEnterLeaveToAncestor): - * 1. a. If A has another pointer, goto 2. - *b. Otherwise, if A has a child with a pointer in it. - * LeaveNotify(Inferior, child(A)) to A. - * EnterNotify(Virtual, child(A)) between A and child(A). - * Skip to 3. - * - * 2. Find closest pointer window P between A and B. - *If P does not exist, P is B. - * LeaveNotify(Ancestor) to A. - * LeaveNotify(Virtual, A) between A and P. - * 3. a. If B has another pointer, finish. - *b. otherwise, EnterNotify(Inferior) to B. + * By inference, this means that only NotifyVirtual or NotifyNonlinearVirtual + * events may have a subwindow set to other than None. */ -#define WID(w) ((w) ? ((w)-drawable.id) : 0) - /** * Return TRUE if @win has a pointer within its boundaries, excluding child
intel X.org crashes on current branches and GM965
Hello, The intel module loads fine (dri, dri2, libglx as well): (II) LoadModule: intel (II) Loading /opt/gfx-test/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor=X.Org Foundation compiled for 1.5.99.3, module version = 2.5.99 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 I even have kdm up and running, but once it loads the KDE 4.1.2 desktop it crashes. To me it looks like the moment when it loads the 3D compositing manager and also the stacktrace suggests that. I missed adding intel and GM965 to the subject line in the first place. That's why I keep the original message attached. Hope somebody recognizes this one: Regards, 7oby 2008/12/18 Tobias Hain tobias.h...@gmx.de wrote: Hello, chipset: GM965 kernel: (vanilla) 2.6.28-rc8, (drm-intel-next) of Eric's 2.6.28-rc8 xserver: server-1.6-branch libdrm: master mesa: master and intel-2008-q4 xf86-video-intel: xf86-video-intel-2.6-branch remaining components: Kubuntu 8.10 I'm facing X.org crashes when launching X with all of the above: Backtrace: 0: /opt/gfx-test/bin/Xorg(xorg_backtrace+0x3b) [0x81323fb] 1: /opt/gfx-test/bin/Xorg(xf86SigHandler+0x51) [0x80b82a1] 2: [0xb7f9b400] 3: /opt/gfx-test/lib/dri/i965_dri.so [0xa75c6a08] 4: /opt/gfx-test/lib/dri/i965_dri.so(intelTexImage2D+0x7e) [0xa75c712e] 5: /opt/gfx-test/lib/dri/i965_dri.so(_mesa_TexImage2D+0x2aa) [0xa76647ea] 6: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a40278] 7: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6a5fb] 8: /opt/gfx-test/lib/xorg/modules/extensions//libglx.so [0xb7a6eb8a] 9: /opt/gfx-test/bin/Xorg(Dispatch+0x33f) [0x808cc6f] 10: /opt/gfx-test/bin/Xorg(main+0x3bd) [0x807192d] 11: /lib/libc.so.6(__libc_start_main+0xe5) [0xb7ad3685] 12: /opt/gfx-test/bin/Xorg [0x8070de1] Fatal server error: Caught signal 11. Server aborting It's always the same crash and related to 3D compositing manager loading I guess. I tried some permutations of the above branches, but none worked. Always the same crash that I didn't have before updating the branches. I've been tracking intel driver development for a while, but not on a regular basis. I think I updated branches one month old and before that everything worked fine. xorg.conf doesn't contain anything special. It's KDE 4.1 compositing manager. Haven't tried anything else yet. Hope it sounds familiar to some. do the drm and intel module load at x startup? i has some similar messages some time ago on radeon caused by modules not autoloading at x startup. i've added them to autoload at startup and then it worked. for some reason after the 1.5 release i couldn't start x without them forcedly loaded by the kernel. try loading the modules manually and see if something changes. -- dott. ing. beso ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
