[ANNOUNCE] libX11 1.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (21): flags member of Display structure needs to be marked volatile Incorporate char range comments from Solaris version of ksc5601.h Incorporate more locale names/aliases from Solaris libX11 Add --with-locale-lib-dir configure option to set locale lib install dir Bug 6820: Xlib shouldn't handle EAGAIN as a fatal IO error Bug 9953: Please provide locale alias hu_HU.utf8 Correct locale alias for sh_ba.iso885...@bosnia (should be sr, not nr) Bug 14651: We need to add new locale specification for Belarusian Latin locale Bug 10082: Compose entries for some standard mathematical operators XErrorDB additions for RANDR 1.3 XErrorDB additions for XInput errors and new XInput 1.5 requests XErrorDB additions for DRI2 requests Remove ifdef checks for macII left over from ancient A/UX 3.0 support When makekeys fails to find a good hash, print error instead of divide-by-zero makekeys: combine malloc(strlen)+strcpy into strdup Remove _XP_PRINT_SERVER_ #ifdefs from Xrm.c Delete some unused #ifdef notdef static functions Change masculine to ordmasculine in Compose file comments Further ansify prototypes reduce #ifdefs in locking.c Fix a several sparse warnings: Using plain integer as NULL pointer Version bump: 1.2.1 Caolan McNamara (1): Bug 20575: man page for XCreatePixmapFromBitmapData doesn't match signature Chris Ball (2): Build fix for fi_FI. Fix fi_FI locale install directory. Emilio Jesús Gallego Arias (1): xcb_io: Avoid datatype overflow on AMD64 and friends. Julien Cristau (2): nls: actually use the fi_FI.UTF-8 files Add a ru_RU.UTF-8 locale Lubos Lunak (2): XGetErrorText() fails for extension error codes equal to the error base XErrorDB updates for XTEST, RANDR, DAMAGE extensions Milos Komarcevic (1): Bug 11456: Serbian locale updates (sr_RS and sr_ME) Paul Bender (1): Bug 15664: xau xdmcp not needed in x11.pc dependencies when built with xcb Xue Wei (4): Add kk_KZ.UTF-8 to locale.dir.pre for Kazakhstan Add locale aliases for no_NO sh_BA locale variants Add nn_NO.UTF-8 to compose.dir.pre for Norwegian Nynorsk Add UTF-8 locale entries for es_US, kk_KZ, mt_MT, and sh_BA Yaakov Selkowitz (Cygwin Ports maintainer) (1): Bug 20773: Xcursor dynamic loading on Cygwin git tag: libX11-1.2.1 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.2.1.tar.bz2 MD5: 2f2beb98e71f397e1209beaca4e97cb1 SHA1: 8e58c3d9070cd164a960dc89b20cf0e35bade8c8 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.2.1.tar.gz MD5: 858e013fd4c37689a2a8d86c8765dab0 SHA1: f9858c7657f9815afd1f2f1516b8da7e4ccf239e - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknb5ewACgkQovueCB8tEw50mQCfYwTTbZnd9zg7x6GIyllmmnfQ JIwAnRCyaCZjrojn9UPMg/avd8rEQ5lS =eXTT -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xpyb 1.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eamon Walsh (4): Print the expected and actual buffer size when a list length calculated Add a wrap() function to create a Connection object from a raw C pointer. Remove auto-generated file. git-tag 1.1 http://xcb.freedesktop.org/dist/xpyb-1.1.tar.gz md5: 29ce8ddf37024b4d1886a44239acd0dc sha1: c2f338a794219989c1d2b615e436db165edf32b7 http://xcb.freedesktop.org/dist/xpyb-1.1.tar.bz2 md5: 0d82bbaa97f89e41aada9fab5630147a sha1: e0d087d7a932e5084c17458f8906a7cd8af5a996 - -- Eamon Walsh ewa...@tycho.nsa.gov National Security Agency -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkncKVcACgkQXKrSC8VF5s22DACgvDOjaQE77tACZSYH1wByXrE3 t/UAn0qMe/82jm37DNAADduVIxN4kVVI =huf2 -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [RFC] glx: fix DRI2 memory leak
On Mon, 2009-04-06 at 14:57 -0700, Jesse Barnes wrote: On Wed, 01 Apr 2009 17:46:08 +0200 Michel Dänzer mic...@daenzer.net wrote: The real problem was pointed out by Pierre Willenbrock: If glxPriv-pDraw is a pixmap, DrawableGone() destroys it, then later DRI2DestroyDrawable dereferences it... The patch below seems to work here - at least it hasn't crashed in a couple of hours, not sure about the leak yet. Note that unless I'm missing something, it might still be possible for this to occur with windows if the underlying DrawableRec is freed before this code is reached. Also, I don't really understand the logic behind clearing glxPriv-pDraw and -drawId here. In particular, I'm not sure DrawableGone will ever be called with glxPriv-refCount 1. If it won't, this change makes the assignments unreachable. And if it will, we'll again leak because the cleanup code won't be able to get to the underlying DrawableRec? So are you happy enough with this fix to push it, Michel? Memory usage is still high on Intel after the fix, but that may be due to bo caching, and this is an important fix... Feel free to push it. It's not really my fix, I just combined the fixes and suggestions from others. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon DPMS problems? backlight turns back on after a minute
On Tuesday 07 April 2009, Lowell Alleman wrote: Are there any known issues with DPMS not working properly with the latest radeon driver? I've found some old bugs that sound similar, but don't exactly match and the workarounds I've found seem to make a difference. Here is what I'm experiencing: My laptop (IBM T42, r300) LCD will not going into power saving mode on its own. If I force it go into one of these modes, it only stays in that mode for a short period of time (a few seconds to a couple of minutes) before the screen turns back on again. I'm pretty sure this isn't due to any keyboard/mouse events (since the screen saver doesn't pop up a login dialog) and I don't see any new events /var/log/acpid that correlate to the LCD being re-enabled. However, every time the LCD turns back on, I do see the following message in the Xorg.0 log file: enable LVDS. It appears that the X server still thinks that the DPMS mode is enabled, because xset q says that the monitor is still in Suspend (or whatever mode I forced it to be in) even after the LCD was turned on again. Here are some additional details about my setup, and what I've tried: Relevant output from xset q: DPMS (Energy Star): Standby: 600Suspend: 660Off: 1200 DPMS is Enabled Monitor is On After the display has been disabled using xset force suspend the display shuts down. If you check xset q it now reports Monitor is in Suspend. A minute or so later the LCD is turned back on. Now I can see screensaver (which is DPMS-aware, and therefore has been paused to save CPU cycles). At this point, xset q still shows Monitor is in Suspend. I've tried switching between EXA and XAA acceleration. As of radeon v6.12.0 XAA says it is not supported any more, but EXA doesn't appear to be the default yet. (Not sure what that means; but in both cases this problems still occurs). I've also tried adding the NoPM option, as I found as an old workaround suggested, but that didn't make a difference either. Versions: X.Org X Server 1.5.2 Radeon driver: 6.12.0 (I compiled this locally for improved performance in latest release) Linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux Kubuntu 8.10 KDE 4.1.4 I can provide additional info (xorg.conf and Xorg.0.log) if this is an unknown situation and those would be helpful to have. Thanks, - Lowell Hi Lowell, this was a bug in the KDE 4 screensaver code [0]. It is certainly fixed in the latest version of KDE. Try updating to KDE 4.2.1 or above. HTH, Magnus [0] http://bugs.kde.org/show_bug.cgi?id=165265 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
X segment fault if use SW cursor
Dear all, When I use SW cursor on XServer 1.6.0, there is a segment fault when display rotation (xrandr --output xxx --rotate left). But it's OK on XServer 1.5.2. I trace the codes and find the cause. The function xxx_crtc_commit will call xf86_reload_cursors(). In xf86_reload_cursors(), cursor_screen_priv = dixLookupPrivate(screen-devPrivates, xf86CursorScreenKey); /* return if HW cursor is inactive, to avoid displaying two cursors */ if (!cursor_screen_priv-isUp) return; In fact, if use SW cursor, I find the cursor_screen_priv is NULL. And X accesses the null pointer. That's why segment fault come out. Maybe we can change it to if(!cursor_screen_priv). Is it a bug on XServer 1.6.0? Thanks! Best wishes, Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Freeglut-developer] [Free]GLUT and MPX
Nothing has changed. The reasons for rejecting the patch still apply. It's cool and all - but it's just not appropriate for FreeGLUT's distro. Once again - I fully understand that. I just wanted to make this patch available to the general public in some way, which is why it's now on our project page. The only place where you could possibly get this patch would be with the 'OpenGLUT' package - which is a fork of freeglut. Unfortunately - that package is no longer maintained - I doubt anyone uses it. Yeah, I've once had a look at that two years ago, and it was already broken then. So the solution is simple: I'll periodically keep that patch up-to-date so it's applicable against FreeGLUT HEAD revision until FreeGLUT 2.6.0 is released update: I just saw that rev. 813 _is_ going to be 2.6.0 - that's nearly perfect, as the patch is for rev. 813 :-) Yours, Florian -- 0666 - Filemode of the Beast ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Recommended X versions for Mobile Intel® GM45 Express Chipset
On Friday 3. April 2009 16.58.48 Li, Yan wrote: Sorry for the late reply. But Moblin v2.0 might be what you have been looking for. Moblin v2.0 ships latest X.org and Intel video drivers and are extensively tested on GM45 (by Intel) so you can expect best stability and performance. Thanks - I guess I will try to have a look at the source/build scripts of X and friends in Moblin and see if I can replicate the version numbers and build system etc in Slackware which is my distribution of choice. But Moblin v2.0 is still in alpha stage so there might still be some problems with it. If it's not one thing, it's the other :-) I'll have a go at it and see! Thanks for your suggestions! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 02:43, Mark Wagner a écrit : I'm busy updating the Linux branch of a cross-platform toolkit that was last updated in 1994. ... Is there a good online document on how to program for XWindows using Xlib? XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. IMHO, if you intend to update your toolkit for another 15 years of use, your should first evaluate switching to a higher-level library such as cairo instead of continuing to use XLib directly. cairo (via pangocairo) will use the modern font stack, and is now a foundation library for gtk, firefox, (soon) OpenOffice.org, and many others. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Nicolas Mailhot nicolas.mail...@laposte.net wrote: XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. And legacy=bad? X core fonts still beat the shit out of the blur-fascist Xft/fontconfig XML-vomit mess with authors/packagers that hate the beautiful Helvetica with a passion. -- Stop Gnomes and other pests! Purchase Windows today! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 11:03, Tuomo Valkonen a écrit : On 2009-04-07, Nicolas Mailhot nicolas.mail...@laposte.net wrote: XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. And legacy=bad? X core fonts still beat the shit out of the blur-fascist Xft/fontconfig XML-vomit mess with authors/packagers that hate the beautiful Helvetica with a passion. A font in 1994 included a few hundreds of glyphs at most without any complex composing rules, and weighted a few kiB. A font in 200x can include thousands of glyphs with complex composing rules, in MiBs of data. And that's just the font-level, without system font substitution management. The core X11 font system just can not scale to modern requirements. And that's ignoring its propensity to crash apps at the slightest excuse. I'm sure there are people who liked the simplicity of CGA screens too. You know what? They were good for their time, but they're history now. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07 11:36 +0200, Nicolas Mailhot wrote: The core X11 font system just can not scale to modern requirements. Works fine for me, good-looking fonts without any effort. Out-of-the-box! Not so with blur-fascist Xft/fontconfig, where you have to compile bytecode interpreters and _sudo_ touch horrible XML and symlink.d vomit. The only problem with core fonts is the blur-fascist elite not bothering to fix UTF-8 fontset support, so there you have some problems. And that's ignoring its propensity to crash apps at the slightest excuse. The requirements haven't changed in twenty years. Screen resolutions still suck. You need fonts specifically designed for screens -- that is, bitmaps, or outline fonts with good hinting for unblurred rendering. Blurring is the approach of the lazy arrogant elite that feeds shit to the masses, and doesn't want to go through the extra work of creating hinting/bitmaps. And when the screen resolutions stop sucking, blurring has defeated itself, as blackwhite rasterisation effects also become unnoticeable. But don't mind me, the last person who wants good fonts. I have already switched to Windows from the sinking ship known as Linux. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and local vendors and artisans have had to yield to all under one roof big box hypermarkets. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 12:27, Tuomo Valkonen a écrit : The requirements haven't changed in twenty years. They have. Systems now have Unicode locale as default, and font foundries do not use the same formats as twenty years ago. What has no changed is that apps using core fonts just crash all the time. Blurring is the approach of the lazy arrogant elite that feeds shit to the masses, You're probably the only person on the list that can't figure how to disable AA in fontconfig if you don't like it. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, 2009-04-07 at 09:03 +, Tuomo Valkonen wrote: On 2009-04-07, Nicolas Mailhot nicolas.mail...@laposte.net wrote: XWindows changed a lot since 1994. Legacy stuff is still available but not really supposed to be used anymore, and in particular (and of special interest to toolkit authors) nowadays to display text you should go through XFT and fontconfig and not use legacy Core X11 font methods. And legacy=bad? X core fonts still beat the shit out of the blur-fascist Xft/fontconfig XML-vomit mess with authors/packagers that hate the beautiful Helvetica with a passion. I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. Obviously if you are too manly to use a desktop environment which provides this then there is the configuration file. I'm going to ignore any xml sucks rant though. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 10:27:37AM +, Tuomo Valkonen wrote: The only problem with core fonts is the blur-fascist elite not bothering to fix UTF-8 fontset support, so there you have some problems. I don't think I ever saw any patches. But don't mind me, the last person who wants good fonts. I have already switched to Windows from the sinking ship known as Linux. 'Don't mind me' and sending a constant stream of irrelevant mails about how the world just don't even know what they want tend to be mutually exclusive. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 12:01:42PM +, Tuomo Valkonen wrote: that need root access to modify. That or an ability to read documentation. (Nobody ever does anything new properly, just adds layers upon layers of indirection, complexity upon complexity. Latest example being the kernel-level keycode standardisation idiocy. Thanks for breaking my .Xmodmap! -- Which I have had to fully store from a pre-Xkb X, as Xkb is another piece of modern shitware that isn't suitable for customisation at all.) xmodmap should work fine these days: if it doesn't, file an actual bug on http://bugs.freedesktop.org, instead of non-specific whining on a mailing list. signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Ross Burton r...@burtonini.com wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. Pollute my system with KDE or Gnome? Rather install Windows. And besides, the big buttons don't remove the anti-bitmap and anti-Helvetica blocks, defoma braindamage, and other layers upon layers of indirection that need root access to modify. (Nobody ever does anything new properly, just adds layers upon layers of indirection, complexity upon complexity. Latest example being the kernel-level keycode standardisation idiocy. Thanks for breaking my .Xmodmap! -- Which I have had to fully store from a pre-Xkb X, as Xkb is another piece of modern shitware that isn't suitable for customisation at all.) -- Be an early adopter! Beat the herd! Choose Windows today! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Tuomo Valkonen wrote: On 2009-04-07, Ross Burton r...@burtonini.com wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. Pollute my system with KDE or Gnome? Rather install Windows. Sounds like a plan. Enjoy your Cleartype. ~ C. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 14:06, Joerg Sonnenberger a écrit : On Tue, Apr 07, 2009 at 01:37:33PM +0200, Nicolas Mailhot wrote: What has no changed is that apps using core fonts just crash all the time. Sorry, but stupid programmers not doing correct validation of return values is NO ARGUMENT. Of course it is when you have to deal with the fallout (either as the entity providing the crash-prone toolkit or as the support entity for apps that use it) I could also misread your statement as programmers that choose to use core fonts are stupid :p Since a lot of them do not do those validations. This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: I'm busy updating the Linux branch of a cross-platform toolkit that was last updated in 1994. The big problem I'm running into is a lack of documentation on how to program for XWindows: the online documentation I've been able to find is at least as old as the toolkit -- for example, one has an appendix detailing the changes from X11R4 to X11R5. Other webpages I've found may be newer, but they don't mention any dates or versions. Is there a good online document on how to program for XWindows using Xlib? Are there programming references for the various extensions, or do I need to work from protocol specifications and uncommented header files? http://www.x.org/docs/ -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
You can argue against the config system, xml is not ideal for manual editing. But, having hinted, aliased fonts isn't impossible. It's pretty simple actually. Providing you have a suitable freetype version. So please put your ranting into perspective. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Are you *really* sure about that? I haven't tried Firefox 3, but older version definitely crashed if fontconfig wouldn't find fonts. Even if the X server itself advertised the presence of core fonts. Joerg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Tuomo Valkonen wrote: The only problem with core fonts is the blur-fascist elite not bothering to fix UTF-8 fontset support, so there you have some problems. If transporting visual information that would otherwise go lost is blurring, then I'm probably not from this world. The implementation isn't ideal (not gamma correct), but switching off is an option. Thanks for the belly laugh! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Simon Thum simon.t...@gmx.de wrote: If transporting visual information that would otherwise go lost is blurring, then I'm probably not from this world. The implementation isn't ideal (not gamma correct), but switching off is an option. Shitty low-resolution computer display hardware can't display that information properly no matter how you mangle it. You have to design simple fonts for it, that it can display properly. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and the cycle paths have been replaced with polluted motorways. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon DPMS problems? backlight turns back on after a minute
On Mon, Apr 6, 2009 at 8:04 PM, Alex Deucher alexdeuc...@gmail.com wrote: On 4/6/09, Lowell Alleman low...@allemansonline.com wrote: Are there any known issues with DPMS not working properly with the latest radeon driver? I've found some old bugs that sound similar, but don't exactly match and the workarounds I've found seem to make a difference. Here is what I'm experiencing: My laptop (IBM T42, r300) LCD will not going into power saving mode on its own. If I force it go into one of these modes, it only stays in that mode for a short period of time (a few seconds to a couple of minutes) before the screen turns back on again. I'm pretty sure this isn't due to any keyboard/mouse events (since the screen saver doesn't pop up a login dialog) and I don't see any new events /var/log/acpid that correlate to the LCD being re-enabled. However, every time the LCD turns back on, I do see the following message in the Xorg.0 log file: enable LVDS. It appears that the X server still thinks that the DPMS mode is enabled, because xset q says that the monitor is still in Suspend (or whatever mode I forced it to be in) even after the LCD was turned on again. It should work fine. If you use xset sometimes events come in after the command to the display comes back on. try: sleep5; xset dpms force off Sorry, I forgot to say that I'm running all of these xset commands remotely (using ssh) to eliminate any kind of local keyboard/mouse interactions like that. ssh u...@host export DISPLAY=:0 xset dpms force off Here are some additional details about my setup, and what I've tried: Relevant output from xset q: DPMS (Energy Star): Standby: 600 Suspend: 660 Off: 1200 DPMS is Enabled Monitor is On After the display has been disabled using xset force suspend the display shuts down. If you check xset q it now reports Monitor is in Suspend. A minute or so later the LCD is turned back on. Now I can see screensaver (which is DPMS-aware, and therefore has been paused to save CPU cycles). At this point, xset q still shows Monitor is in Suspend. I've tried switching between EXA and XAA acceleration. As of radeon v6.12.0 XAA says it is not supported any more, but EXA doesn't appear to be the default yet. (Not sure what that means; but in both cases this problems still occurs). I've also tried adding the NoPM option, as I found as an old workaround suggested, but that didn't make a difference either. XAA is still supported. There is just no render accel with XAA on r3xx and newer chips. Blits/fills/lines/etc. are still accelerated with XAA, but EXA is generally preferable. Versions: X.Org X Server 1.5.2 Radeon driver: 6.12.0 (I compiled this locally for improved performance in latest release) Linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux Kubuntu 8.10 KDE 4.1.4 I can provide additional info (xorg.conf and Xorg.0.log) if this is an unknown situation and those would be helpful to have. Thanks, - Lowell ___ xorg mailing list x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Le Mar 7 avril 2009 14:52, Joerg Sonnenberger a écrit : On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: This is not something specific to core fonts. Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Are you *really* sure about that? I haven't tried Firefox 3, but older version definitely crashed if fontconfig wouldn't find fonts. 1. IIRC very old firefox versions used gtk1 and core fonts and crashed like other core fonts users (I run Fedora devel, so my old is relative) 2. I haven't seen any widespread case of fontconfig not finding fonts in Fedora in the past years. I've seen sporadic one-of reports where someone did something stupid, such as making fontconfig caches RO, but nothing remotely like core fonts crashes (and I'm CCed on most Fedora font bug reports nowadays). However googling a bit I see others distros may not be as careful to run fc-cache timely on font install. We do regularly have reports of core font related crashes and they do outnumber fontconfig problems even though as this stage almost all the distro uses fontconfig instead. 3. There are persistent reports of firefox weirdness if fontconfig is updated while a firefox instance is running, but usually mostly cosmetic and not affecting other apps, so I guess Mofo has a buglet somewhere. Restarting firefox cleans up things. 4. pre-release fontconfig versions have bugs as other software and we see them in fedora-devel. Though usually with cosmetic effects only (font mis-selection, not crashes) Mostly, fontconfig users complain font selection heuristics or rendering settings are not as good as they should be. Core font users OTOH have problems just getting their apps to run reliably. -- Nicolas Mailhot ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Date: Tue, 7 Apr 2009 13:37:33 +0200 (CEST) From: Nicolas Mailhot nicolas.mail...@laposte.net Le Mar 7 avril 2009 12:27, Tuomo Valkonen a écrit : The requirements haven't changed in twenty years. They have. Systems now have Unicode locale as default, and font foundries do not use the same formats as twenty years ago. What has no changed is that apps using core fonts just crash all the time. H... Funny: our applications, built primarily even predating X11, just /don't/ crash. Period. Using core fonts. (If they do, it's the X server that causes the problem, not the app.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Nice theory. Kinda breaks down when you find out that pango_font_metrics_get_approximate_char_width answers 0 on such a subtitution. Pretending that fontconfig/pango is bug-free is just out there. OG. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 04/07/2009 11:11 AM, Olivier Galibert wrote: On Tue, Apr 07, 2009 at 02:32:38PM +0200, Nicolas Mailhot wrote: Fontconfig-using apps do not crash for lack of fonts, because fontconfig has built-in font substitution Nice theory. Kinda breaks down when you find out that pango_font_metrics_get_approximate_char_width answers 0 on such a subtitution. So what? Remove all your fonts (or pango.modules file) and Pango happily works. Draws boxes though. See attachment. But thanks for the report. Fixing. I've recently added an internal font to cairo. In near future, Pango will happily fallback to that. Pretending that fontconfig/pango is bug-free is just out there. No one's pretending that. behdad attachment: gedit-boxes.png___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Date: Tue, 7 Apr 2009 16:50:26 +0100 From: Alan Cox a...@lxorguk.ukuu.org.uk Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Why would an application programmer want to be using Xlib directly ? Frankly, you're right. Today. Unfortunately, I'm in the position of supporting a substrate for several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions that entails built in to more layers of the system than was warranted even at the time, but...) I don't have the luxury of ripping all that out and replacing it with cairo/pango with all the learning curve, development time, and regression testing that would entail. Our team does not have the time budget for anything like that. Our customers are a very conservative lot, too, and do not react well if we need to tell them to change their systems just becase a new version of some library we're depending on comes out. Stability is crucial. (Did I mention mission-critical.) Realize that the Xlib portion of my job description is a small fraction of my duties. The Xlib applications are the most stable of our suite, and other than trying to (now) track X.Org changes in basic functionality, the development on that portion of our code is nil. Development of new tools and applications (not on Xlib, by the way) takes priority by far. I'd be very surprised if I was alone in this situation. There is good documentation for things like pango and cairo but then you've clearly not looked. I would imagine nobody bothered to reply to such queries because they though you should learn to use a search engine. Being condescending and insulting is not helpful. Cairo/pango is not what I was looking for. What would /you/ call it if you asked me for help to find a hammer -- which failed to appear in hours of searching -- and I don't bother to answer because I think you don't know how to search for a screwdriver? I would at least be more helpful if I suggested that a screw would be a better fastener than a nail (no one even mentioned cairo/pango as a possible help to me -- until your snideness mentioned them), but if you really had to use the nail for some reason, the hammer is what you need. In a fairer universe, I'd be able to step up and offer the time necessary to learn the changes and write the documenation folks like me seek for X.Org. Though, that may be the help that is needed -- I've been told more than a few times that documentation I write is not easily understood :-(. I'd be happy if I had the time to support the back-compatibilty in X core functionality that we're depending on. Alas, this universe is not so kind. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon DPMS problems? backlight turns back on after a minute
On Tuesday 07 April 2009, Lowell Alleman wrote: On Tue, Apr 7, 2009 at 3:05 AM, Magnus Kessler magnus.kess...@gmx.net wrote: On Tuesday 07 April 2009, Lowell Alleman wrote: Are there any known issues with DPMS not working properly with the latest radeon driver? I've found some old bugs that sound similar, but don't exactly match and the workarounds I've found seem to make a difference. Here is what I'm experiencing: My laptop (IBM T42, r300) LCD will not going into power saving mode on its own. If I force it go into one of these modes, it only stays in that mode for a short period of time (a few seconds to a couple of minutes) before the screen turns back on again. I'm pretty sure this isn't due to any keyboard/mouse events (since the screen saver doesn't pop up a login dialog) and I don't see any new events /var/log/acpid that correlate to the LCD being re-enabled. However, every time the LCD turns back on, I do see the following message in the Xorg.0 log file: enable LVDS. It appears that the X server still thinks that the DPMS mode is enabled, because xset q says that the monitor is still in Suspend (or whatever mode I forced it to be in) even after the LCD was turned on again. Here are some additional details about my setup, and what I've tried: Relevant output from xset q: DPMS (Energy Star): Standby: 600Suspend: 660Off: 1200 DPMS is Enabled Monitor is On After the display has been disabled using xset force suspend the display shuts down. If you check xset q it now reports Monitor is in Suspend. A minute or so later the LCD is turned back on. Now I can see screensaver (which is DPMS-aware, and therefore has been paused to save CPU cycles). At this point, xset q still shows Monitor is in Suspend. I've tried switching between EXA and XAA acceleration. As of radeon v6.12.0 XAA says it is not supported any more, but EXA doesn't appear to be the default yet. (Not sure what that means; but in both cases this problems still occurs). I've also tried adding the NoPM option, as I found as an old workaround suggested, but that didn't make a difference either. Versions: X.Org X Server 1.5.2 Radeon driver: 6.12.0 (I compiled this locally for improved performance in latest release) Linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux Kubuntu 8.10 KDE 4.1.4 I can provide additional info (xorg.conf and Xorg.0.log) if this is an unknown situation and those would be helpful to have. Thanks, - Lowell Hi Lowell, this was a bug in the KDE 4 screensaver code [0]. It is certainly fixed in the latest version of KDE. Try updating to KDE 4.2.1 or above. HTH, Magnus [0] http://bugs.kde.org/show_bug.cgi?id=165265 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Hey Magnus, Thanks for that link. I do think that that bug is *part* of my problem, but not *all* of it. (I plan on upgrading to Kubuntu 9.04, which has KDE 4.2.x once it is released last this month.) Based on the info in that bug report, I ran the following test: I set my screen saver to come on after 5 minutes. Then I ran xset dpms 5 10 15. The screen does blank after 5 seconds, but it then comes back on after about 2 seconds, with the screen saver visible in the background (which was unexpected.) Then at the 10 second mark, the screen turns off again and comes back on after a few minutes. One general observation is that it seems like the first time the LCD enters a power saving mode, it lasts for only a few seconds. Then each additional switch into powersavings mode lasts for about a minute or two. (When I say first time, I mean after an Xorg restart.) Just to rule out KDE as the whole problem, I'm going to try starting up in a different environment; perhaps some failsafe xterm mode. I'll let you know what I find. - Lowell I have had an instance or two where old batteries in the mouse caused a one pixel movement when the mouse wasn't being touched. hat will unblank it. I changed batteries a couple of times, then changed the mouse. End of problem... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- 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) When anyone says `theoretically,' they really mean `not really.' -- David Parnas ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Why would an application programmer want to be using Xlib directly ? There is good documentation for things like pango and cairo but then you've clearly not looked. I would imagine nobody bothered to reply to such queries because they though you should learn to use a search engine. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Changing Xorg-Configuration on the fly
Hello, as part of a project I'm coding a calibration tool and I'm looking for a way to tell the xserver to change some of its settings on the fly. Yes, I know the xrandr-extension, but I don't think its what I need (if I am wrong feel free to correct me...). In the ServerLayout Section of the xorg.conf I defined the following Xinerama settings: Screen Screen0 Absolute 0 0 Screen Screen1 Absolute 1585 855 Screen Screen2 Absolute 0 860 Screen Screen3 Absolute 1585 0 Now I want to change the defined X- and Y-coordinates while the xserver is running - of course without restarting it. How can I do this, or where can I find appropriate functions that will help me to do the job? Thanks in advance, Leif ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. I'd be very surprised if I was alone in this situation. Probably not although I suspect the need to provide accessibility in much software today is finally burying the hatchet. Being condescending and insulting is not helpful. I was replying in a style consistent with your email In a fairer universe, I'd be able to step up and offer the time necessary to learn the changes and write the documenation folks like me seek for X.Org. Though, that may be the help that is needed -- I've been told more than a few times that documentation I write is not easily understood :-(. I'd be happy if I had the time to support the back-compatibilty in X core functionality that we're depending on. Alas, this universe is not so kind. There shouldn't be any breakage of compatibility in old old apps. You may have problems with fonts and with some extra libraries where the distribution vendors no longer ship those extensions by default or at all. That is much more a distribution change and since extensions are exactly that quite allowable (if annoying in some cases) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 04/07/2009 11:33 AM, Behdad Esfahbod wrote: Nice theory. Kinda breaks down when you find out that pango_font_metrics_get_approximate_char_width answers 0 on such a subtitution. On further inspection, does it? Do you have a test case? It does return if you pass a NULL object to it, but that's a programming error, not missing fonts. behdad ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Mon, 2009-04-06 at 17:43 -0700, Mark Wagner wrote: Are there programming references for the various extensions, or do I need to work from protocol specifications and uncommented header files? Much of the old Xlib documentation was paid for by the Open Group or its predecessors. No one's paid to write new doc in ~10 years or so. For many of the extensions, the API is a straightforward mapping to the protocol, and the protocol documentation attempts to be sufficiently comprehensive. If it's not, please let us know! Is this the best mailing list for any questions I have, or is there a better one? This one's fine, yes. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, 2009-04-07 at 12:01 +, Tuomo Valkonen wrote: On 2009-04-07, Ross Burton r...@burtonini.com wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. Pollute my system with KDE or Gnome? Rather install Windows. Don't let the door hit you in the ass on the way out. - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon DPMS problems? backlight turns back on after a minute
On Tue, Apr 7, 2009 at 9:31 AM, Lowell Alleman low...@allemansonline.com wrote: On Tue, Apr 7, 2009 at 3:05 AM, Magnus Kessler magnus.kess...@gmx.net wrote: On Tuesday 07 April 2009, Lowell Alleman wrote: Are there any known issues with DPMS not working properly with the latest radeon driver? I've found some old bugs that sound similar, but don't exactly match and the workarounds I've found seem to make a difference. Here is what I'm experiencing: My laptop (IBM T42, r300) LCD will not going into power saving mode on its own. If I force it go into one of these modes, it only stays in that mode for a short period of time (a few seconds to a couple of minutes) before the screen turns back on again. I'm pretty sure this isn't due to any keyboard/mouse events (since the screen saver doesn't pop up a login dialog) and I don't see any new events /var/log/acpid that correlate to the LCD being re-enabled. However, every time the LCD turns back on, I do see the following message in the Xorg.0 log file: enable LVDS. It appears that the X server still thinks that the DPMS mode is enabled, because xset q says that the monitor is still in Suspend (or whatever mode I forced it to be in) even after the LCD was turned on again. Here are some additional details about my setup, and what I've tried: Relevant output from xset q: DPMS (Energy Star): Standby: 600 Suspend: 660 Off: 1200 DPMS is Enabled Monitor is On After the display has been disabled using xset force suspend the display shuts down. If you check xset q it now reports Monitor is in Suspend. A minute or so later the LCD is turned back on. Now I can see screensaver (which is DPMS-aware, and therefore has been paused to save CPU cycles). At this point, xset q still shows Monitor is in Suspend. I've tried switching between EXA and XAA acceleration. As of radeon v6.12.0 XAA says it is not supported any more, but EXA doesn't appear to be the default yet. (Not sure what that means; but in both cases this problems still occurs). I've also tried adding the NoPM option, as I found as an old workaround suggested, but that didn't make a difference either. Versions: X.Org X Server 1.5.2 Radeon driver: 6.12.0 (I compiled this locally for improved performance in latest release) Linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux Kubuntu 8.10 KDE 4.1.4 I can provide additional info (xorg.conf and Xorg.0.log) if this is an unknown situation and those would be helpful to have. Thanks, - Lowell Hi Lowell, this was a bug in the KDE 4 screensaver code [0]. It is certainly fixed in the latest version of KDE. Try updating to KDE 4.2.1 or above. HTH, Magnus [0] http://bugs.kde.org/show_bug.cgi?id=165265 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Hey Magnus, Thanks for that link. I do think that that bug is *part* of my problem, but not *all* of it. (I plan on upgrading to Kubuntu 9.04, which has KDE 4.2.x once it is released last this month.) Based on the info in that bug report, I ran the following test: I set my screen saver to come on after 5 minutes. Then I ran xset dpms 5 10 15. The screen does blank after 5 seconds, but it then comes back on after about 2 seconds, with the screen saver visible in the background (which was unexpected.) Then at the 10 second mark, the screen turns off again and comes back on after a few minutes. One general observation is that it seems like the first time the LCD enters a power saving mode, it lasts for only a few seconds. Then each additional switch into powersavings mode lasts for about a minute or two. (When I say first time, I mean after an Xorg restart.) Just to rule out KDE as the whole problem, I'm going to try starting up in a different environment; perhaps some failsafe xterm mode. I'll let you know what I find. - Lowell Ok. I did some additional testing and I can confirm that this ONLY is a problem when I'm running KDE. And while using KDE, it seems that If I stick with just DPMS modes and disable the sceensaver, then my LCD will shut off as it should. (Thanks again Magnus for pointing me in the right direction.) So one final question. Why does xset q still report Monitor is in Suspend after the display has turned back on? It is clear that at least at some level X knows that the Monitor has been turned on again because I see the message enable LVDS in the Xorg.log file each time the display turns back on. Is this a bug or is there a legitimate reason for this discrepancy? Any thoughts? - Lowell ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-nv 2.1.13
Aaron Plattner (2): Only match PCI display devices in our display driver. Add NV_/RIVA_ prefixes to fix build warnings. Adam Jackson (4): Adjust the nv34 panel tweak for Toshiba Tecra M2. Do E-EDID if built against a server that supports it. Remove README.NV1 nv 2.1.13 Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Bryce Harrington (1): Add missing pci id for GeForce 7100 GS Chris Ball (3): Build fix, s/pNv-/pRiva-/. Build fix: set EXA_DRIVER_KNOWN_MAJOR=3 Revert Build fix: set EXA_DRIVER_KNOWN_MAJOR=3 git tag: xf86-video-nv-2.1.13 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.13.tar.bz2 MD5: c3231c8808a11eb4ca066e43e0f1a273 xf86-video-nv-2.1.13.tar.bz2 SHA1: 47aa26d8d21773eb5d03a931482a87a75d9168ab xf86-video-nv-2.1.13.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-nv-2.1.13.tar.gz MD5: b8842b7d0aad6e4b8f5423d32e200b9e xf86-video-nv-2.1.13.tar.gz SHA1: 1484fe4d615a512ff4f35e6423b28c1a0933f2b9 xf86-video-nv-2.1.13.tar.gz - ajax signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: I'm busy updating the Linux branch of a cross-platform toolkit that was last updated in 1994. ... Is there a good online document on how to program for XWindows using Xlib? Are there programming references for the various extensions, or do I need to work from protocol specifications and uncommented header files? This isn't strictly programming related, but if you haven't read it yet http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/ is quite helpful for understanding the reason for many of the more recent X developments. -Nathan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Daniel Stone dan...@fooishbar.org wrote: On Tue, Apr 07, 2009 at 12:01:42PM +, Tuomo Valkonen wrote: that need root access to modify. That or an ability to read documentation. A 1000 page developer document for a simple setting. YUP. That is indeed the typical approach to everything in Linux these days. fontconfig, udev, Xft, HAL, everything. Even gtk itself has all the simplest configuration documentation hidden within API documentation. No thanks. The best configuration files are the self-documenting ones. In Linux/FOSS these days, it's essentially complicated _program source code_ in a fancy non-programming language (XML) syntax that is supposed to be used for configuration as well. It screams out loud: POWER USERS: VANISH! THIS OS IS FOR DEVELOPERS AND UNDEMANDING IDIOT USERS ONLY! -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and the cycle paths have been replaced with polluted motorways. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Ross Burton wrote: I can't believe I'm feeding the troll, but in GNOME (and KDE I'm sure) there is a nice big Antialiasing: off button in the font configuration. And where is the Prefer legibility over getting the exact physical size to within a nanometre button? -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-intel SDVO TV xrandr support for TV_FORMAT
Hi xf86-video-intel folks, Are there any plans to support the ability to set the TV_FORMAT (PAL, NTSC, etc.) on SDVO TV output using Xrandr (or even through xorg.conf)? Right now, it looks like it is pretty much hardcoded to NTSC-M (i830_sdvo_set_tv_format in i30_sdvo.c). Thanks Hugo Jacques This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Patrick O'Donnell wrote: that need root access to modify. That or an ability to read documentation. Hmmm.. It seems to me that that's how this thread started, and the original question has yet to be answered. Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Oh? Would you care to elaborate? Like, what is *actually* missing? I have made similar queries on this list for documentation, with similar lack of results. IOW, you ask, people answer, you don't like the answer (probably because you didn't ask the right question in the first place), then claim that no-one answered. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Daniel Stone dan...@fooishbar.org wrote: That or an ability to read documentation. 1000-page developer documention. Yup. That's the approach to most things in Linux these days. fontconfig, Xft, udev, HAL, all screaming out loud POWER USERS: VANISH! THIS OS IS FOR DEVELOPERS AND UNDEMANDING IDIOT USERS ONLY! With so-called configuration files actually being program source code, often mangled into a non-programing language (XML) mess, and the mostly non-existent documention hidden within developer documention (as is the case with gtk, although with proper configuration files). The best configuration file is the concise and self-documenting one. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and local vendors and artisans have had to yield to all under one roof big box hypermarkets. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, 7 Apr 2009 18:36:20 + (UTC), Tuomo Valkonen wrote: On 2009-04-07, Alan Cox a...@lxorguk.ukuu.org.uk wrote: several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. Try a 5 year old Linux program binary on a recent OS -- and weep. Hmm... Name: chromium Relocations: (not relocatable) Version : 0.9.12Vendor: Red Hat, Inc. Release : 21Build Date: Wed 29 Jan 2003 14:40:10 GMT Install Date: Sat 31 Jan 2009 17:59:57 GMT Build Host: sylvester.devel.redhat.com I wasn't weeping the other day when I was happily playing this under fedora 10. Does that qualify as recent?. Cheers anyway. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Corbin Simpson mostawesomed...@gmail.com wrote: Pollute my system with KDE or Gnome? Rather install Windows. Sounds like a plan. Enjoy your Cleartype. Plan executed and succesfully accomplished. Byebye Linux. Windows XP has a simple option to disable blurring -- actually it isn't even enabled by default for small fonts. In Vista and W7 it's complicated, but still doable (most easily by choosing a suitable theme, although there's no longer a simple option on W7). OS X is the most fascist of them all; there is no way at all to disable blurring on it, AFAIK. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and the cycle paths have been replaced with polluted motorways. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 2009-04-07, Alan Cox a...@lxorguk.ukuu.org.uk wrote: several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. Try a 5 year old Linux program binary on a recent OS -- and weep. Try a less-than-year old Linux OS with a recent program binary -- and weep Try the 8-year-old Windows XP, and a recent program binary -- no problems. -- Stop Gnomes and other pests! Purchase Windows today! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On 04/07/2009 02:19 PM, Tuomo Valkonen wrote: On 2009-04-07, Daniel Stonedan...@fooishbar.org wrote: On Tue, Apr 07, 2009 at 12:01:42PM +, Tuomo Valkonen wrote: that need root access to modify. That or an ability to read documentation. A 1000 page developer document for a simple setting. YUP. That is indeed the typical approach to everything in Linux these days. fontconfig, udev, Xft, HAL, everything. Even gtk itself has all the simplest configuration documentation hidden within API documentation. No thanks. The best configuration files are the self-documenting ones. In Linux/FOSS these days, it's essentially complicated _program source code_ in a fancy non-programming language (XML) syntax that is supposed to be used for configuration as well. It screams out loud: POWER USERS: VANISH! THIS OS IS FOR DEVELOPERS AND UNDEMANDING IDIOT USERS ONLY! Why are you still wasting your time here then? Srsly, dude, get away from your keyboard. Go out for a walk, enjoy the weather, have a good time. behdad ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Using Xorg, XDM seems to be ignoring my keyboard
Pantherman wrote: I installed GNOME some time ago on my laptop, but liked the enlightened window manger better, so i went back and installed the Ubuntu system with the Alternate CD installing only the Linux base and using Apt-get install to install Xorg, GDM and e16. Keyboard works fine in the console and all the ALT-F1-F6 consoles, but not in GDM. In GDM neither the keybaord or mouse work (Both worked when I was using GNOME). Are there some Xorg drivers that I'm not installing that I need to? Pantherman Thanks guys for the suggestions, turns out that the HAL software wasn't installed and [Aptitude install hal] actually got me what I needed, thanks again guys!! Pantherman -- View this message in context: http://www.nabble.com/Using-Xorg%2C-XDM-seems-to-be-ignoring-my-keyboard-tp22860374p22937472.html Sent from the Free Desktop - xorg mailing list archive at Nabble.com. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Date: Tue, 7 Apr 2009 17:56:01 +0100 From: Alan Cox a...@lxorguk.ukuu.org.uk several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. A good point. I'd be very surprised if I was alone in this situation. Probably not although I suspect the need to provide accessibility in much software today is finally burying the hatchet. Another. We're not running into that one in our market (yet). There shouldn't be any breakage of compatibility in old old apps. ... Perhaps not compatibility, strictly speaking, but we're going to miss our old friends backing store and save unders. Their demise feels like a breakage of compatibility, as the X servers we've used have all had reasonably aggressive offering of the optimizations (til now). (We have been strongly depending on their existence, incorrectly.) One of our applications has a very expensive redraw cycle that we now have to decide how we are going to manage when backing store is not being supplied. This extra work at this point in time creates a certain amount of frustration that I impolitely let show in my earlier e-mail. - Patrick ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 7, 2009 at 10:07, Adam Jackson a...@nwnk.net wrote: On Mon, 2009-04-06 at 17:43 -0700, Mark Wagner wrote: Are there programming references for the various extensions, or do I need to work from protocol specifications and uncommented header files? Much of the old Xlib documentation was paid for by the Open Group or its predecessors. No one's paid to write new doc in ~10 years or so. For many of the extensions, the API is a straightforward mapping to the protocol, and the protocol documentation attempts to be sufficiently comprehensive. If it's not, please let us know! Thanks. Is there any documentation on the best way to do various high-level tasks, such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. A good howto on dealing with copy/paste would also be useful. Is this the best mailing list for any questions I have, or is there a better one? This one's fine, yes. Seems a bit prone to flamewars, though. -- Mark Wagner ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
From: Glynn Clements gl...@gclements.plus.com Date: Tue, 7 Apr 2009 19:44:19 +0100 Patrick O'Donnell wrote: Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. Oh? Would you care to elaborate? Like, what is *actually* missing? The first thing to come to mind is a guide to what's even in that directory. If you already know what all the abbreviations and initializms are, then you can probably find what you're looking for without too much trouble. If not, it's pretty much hit-and-miss. Also, something to glue all the pieces together -- to tell the application programmer where each piece fits in the whole puzzle, where to use it, when to use it, and equally important, when not to. Something like the old Xlib Programmer's Guide. Reference information where you must infer the API from protocol specs is hard enough to grok. Trying to put together a coherent big picture from the scattered bits takes a lot of time that someone trying to get a product out the door doesn't have. I have made similar queries on this list for documentation, with similar lack of results. IOW, you ask, people answer, you don't like the answer (probably because you didn't ask the right question in the first place), then claim that no-one answered. IOW, I ask, people answer a different question, and they blame me for not asking the question they wanted to answer in the first place. Then, they claim the answered my question. H ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Bad Commit
2009/4/7 Eric Anholt e...@anholt.net: On Tue, 2009-04-07 at 09:49 +0800, Fu Michael wrote: Mike Lothian wrote: Could commit: drm/i915: Use LVDS config in Driver feature BDB for integrated LVDS check ed356c1946edc4017799de0371ef229bffa5e72c Be removed from the drm-intel-next branch please It caused KMS to break for me on my Intel(R) Mobile Intel GM45 Express Chipset It's rare to see this bits are invalid for a new platform such as GM45 based platform. What's the specific model of your machine? The code's been removed from the branch for a while, anyway. I have a Samsung R510 It's awful, I can't control the brightness on it either and it crashes sometimes when it's unplugged. (Never on Vista but does on Windows 7 so maybe samsung might fix it) The were cheep and used the same bios to control the Intel and Nvidia options causing a plethora of problems for me I'll happily try any patches which might help with this. I noticed Linus' 2.6 tree doesn't boot at the moment (different issue) but there's that many changes it could be lots of things. I'll git bisect that next. Cheers Mike ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, 7 Apr 2009, Alan Cox wrote: On Tue, 7 Apr 2009 18:36:20 + (UTC) Tuomo Valkonen tuo...@iki.fi wrote: On 2009-04-07, Alan Cox a...@lxorguk.ukuu.org.uk wrote: several mission-critical applications that has seen two and a half decades of development based on Xlib. (... with all the assumptions Commiserations but at least Xlib today is back compatible. Try a 25 year old windows app and weep. Try a 5 year old Linux program binary on a recent OS -- and weep. Works beautifully if you have the libraries to hand. I test this ^^ (big assumption). regularly and things like the rogue binary from 1993 work nicely. The number of interfaces we removed is tiny and all specialist Since 1993 seems to be your message. Of course you _could_ give an informative response. ctype's changed incompatibly a couple of times (I assume that's what you mean by specialist). Of course that's glibc (termio's changed at least once - I recall hearing that was kernel ;-). (curious if you're planning to make remarks that distinguish you from Tuomo - so far, that's not the case) awai -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
From: Patrick O'Donnell p...@ascent.com From: Glynn Clements gl...@gclements.plus.com Patrick O'Donnell wrote: I have made similar queries on this list for documentation, with similar lack of results. IOW, you ask, people answer, you don't like the answer (probably because you didn't ask the right question in the first place), then claim that no-one answered. IOW, I ask, people answer a different question, and they blame me for not asking the question they wanted to answer in the first place. Then, they claim the answered my question. H On re-reading, I realize that this is unfair to those who did answer and offered their help, and to those who might have been offended, I apologize. I should not have succumbed to the temptation to respond to a provocation that was not deserving of a response. It is unfortunate that the same lack of funds/time that preclude comprehensive documentation of the latest in advancements in X also precludes many of us who might want to from sussing out what we need from the implementation details that are avaiable. It's a catch-22 that makes it difficult to effectively and efficiently update old X applications that need it. The lack of comprehensive documentation also precludes one without the time to pursue in-depth understanding of the details of recent X developments from developing the ability to know if the question they ask is the right one. Nevertheless, the asking of a question, even the wrong one, indicates a void in the asker's understanding that they wish to fill. Dismissing the asker simply because their void is larger than they realized is a great way to turn away a potential advocate, or to lose one who once was an advocate but is becoming disillusioned. - Patrick ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Patrick O'Donnell wrote: Someone offered up www.x.org/docs, which may be fine for X Window System developers, but is not what most application programmers would call documentation. There's also http://www.x.org/wiki/Documentation which isn't much better, but is a little more friendly than a list of directory names. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: Thanks. Is there any documentation on the best way to do various high-level tasks Xlib is all about low-level tasks, and very intentionally leaves high-level tasks to the various toolkits. In order to get much lower level than Xlib, you'd have to use write() directly on the socket... , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. Seven seconds! The last time I saw a splashscreen take that long to draw, the app was doing a million XSetForeground/XDrawPoint pairs, instead of one single XPutImage. Without knowing exactly what you're doing, it is difficult to suggest improvements. A good howto on dealing with copy/paste would also be useful. As far as I know, not much has changed since the ICCCM was last updated ~15 years ago, aside from newer apps preferring the UTF-8 encoding for text. ICCCM: http://tronche.com/gui/x/icccm/sec-2.html#s-2 UTF8_STRING: http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/UTF8_STRING.text Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 7, 2009 at 15:37, Peter Harris phar...@opentext.com wrote: Mark Wagner wrote: , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. Seven seconds! The last time I saw a splashscreen take that long to draw, the app was doing a million XSetForeground/XDrawPoint pairs, instead of one single XPutImage. Without knowing exactly what you're doing, it is difficult to suggest improvements. I believe the slow part is a million calls to XAllocColor(). Since it works (if slowly), I haven't looked too closely at it. I've been concentrating on implementing features that are present in the Mac and Windows branches of the toolkit, but not the Linux branch. A good howto on dealing with copy/paste would also be useful. As far as I know, not much has changed since the ICCCM was last updated ~15 years ago, aside from newer apps preferring the UTF-8 encoding for text. And it was just as complicated then as it is now, especially compared to the Windows SetClipboardData()/GetClipboardData() method. -- Mark Wagner ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] libX11 1.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan Coopersmith (21): flags member of Display structure needs to be marked volatile Incorporate char range comments from Solaris version of ksc5601.h Incorporate more locale names/aliases from Solaris libX11 Add --with-locale-lib-dir configure option to set locale lib install dir Bug 6820: Xlib shouldn't handle EAGAIN as a fatal IO error Bug 9953: Please provide locale alias hu_HU.utf8 Correct locale alias for sh_ba.iso885...@bosnia (should be sr, not nr) Bug 14651: We need to add new locale specification for Belarusian Latin locale Bug 10082: Compose entries for some standard mathematical operators XErrorDB additions for RANDR 1.3 XErrorDB additions for XInput errors and new XInput 1.5 requests XErrorDB additions for DRI2 requests Remove ifdef checks for macII left over from ancient A/UX 3.0 support When makekeys fails to find a good hash, print error instead of divide-by-zero makekeys: combine malloc(strlen)+strcpy into strdup Remove _XP_PRINT_SERVER_ #ifdefs from Xrm.c Delete some unused #ifdef notdef static functions Change masculine to ordmasculine in Compose file comments Further ansify prototypes reduce #ifdefs in locking.c Fix a several sparse warnings: Using plain integer as NULL pointer Version bump: 1.2.1 Caolan McNamara (1): Bug 20575: man page for XCreatePixmapFromBitmapData doesn't match signature Chris Ball (2): Build fix for fi_FI. Fix fi_FI locale install directory. Emilio Jesús Gallego Arias (1): xcb_io: Avoid datatype overflow on AMD64 and friends. Julien Cristau (2): nls: actually use the fi_FI.UTF-8 files Add a ru_RU.UTF-8 locale Lubos Lunak (2): XGetErrorText() fails for extension error codes equal to the error base XErrorDB updates for XTEST, RANDR, DAMAGE extensions Milos Komarcevic (1): Bug 11456: Serbian locale updates (sr_RS and sr_ME) Paul Bender (1): Bug 15664: xau xdmcp not needed in x11.pc dependencies when built with xcb Xue Wei (4): Add kk_KZ.UTF-8 to locale.dir.pre for Kazakhstan Add locale aliases for no_NO sh_BA locale variants Add nn_NO.UTF-8 to compose.dir.pre for Norwegian Nynorsk Add UTF-8 locale entries for es_US, kk_KZ, mt_MT, and sh_BA Yaakov Selkowitz (Cygwin Ports maintainer) (1): Bug 20773: Xcursor dynamic loading on Cygwin git tag: libX11-1.2.1 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.2.1.tar.bz2 MD5: 2f2beb98e71f397e1209beaca4e97cb1 SHA1: 8e58c3d9070cd164a960dc89b20cf0e35bade8c8 http://xorg.freedesktop.org/archive/individual/lib/libX11-1.2.1.tar.gz MD5: 858e013fd4c37689a2a8d86c8765dab0 SHA1: f9858c7657f9815afd1f2f1516b8da7e4ccf239e - -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (SunOS) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknb5ewACgkQovueCB8tEw50mQCfYwTTbZnd9zg7x6GIyllmmnfQ JIwAnRCyaCZjrojn9UPMg/avd8rEQ5lS =eXTT -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Documentation?
-Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Mark Wagner Sent: Tuesday, April 07, 2009 4:15 PM To: Peter Harris Cc: xorg@lists.freedesktop.org Subject: Re: Documentation? On Tue, Apr 7, 2009 at 15:37, Peter Harris phar...@opentext.com wrote: Mark Wagner wrote: , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. I believe the slow part is a million calls to XAllocColor(). Ahh, that's what's going on in my code I wrote last week. I was writing a quick demo program using Xaw and tried to use the display list stuff to load a XPM image into some of the label widgets. In my case, one image takes approximately 20 seconds while the second image takes over a minute! The worked fast once they were used once. I gave up and wrote some code to load a PPM image into a Pixmap. Took about 30 minutes to write. There is no noticable delay in loading either image now. Of course I'm cheating. I have 24bit images going into a 24bit true color visual. Anyway, if you can control the image format that's being loaded, don't be scared off from rolling your own code. Mike McDonald ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
Mark Wagner wrote: On Tue, Apr 7, 2009 at 15:37, Peter Harris phar...@opentext.com wrote: Mark Wagner wrote: , such as drawing images? One of the big things I need to update is the toolkit's image-handling code: right now, a simple JPEG splashscreen takes seven seconds to draw. Seven seconds! The last time I saw a splashscreen take that long to draw, the app was doing a million XSetForeground/XDrawPoint pairs, instead of one single XPutImage. Without knowing exactly what you're doing, it is difficult to suggest improvements. I believe the slow part is a million calls to XAllocColor(). Since it works (if slowly), I haven't looked too closely at it. I've been concentrating on implementing features that are present in the Mac and Windows branches of the toolkit, but not the Linux branch. Yes, a million XAllocColor calls will hurt, since each one costs a round-trip. Over the network, that adds up to minutes. Even on a local display, that's still two million context switches. Unless you need to maintain support for legacy (PseudoColor) displays, there really isn't a reason to call XAllocColor any more. Even if you do need to work on a PseudoColor display, you're far better off allocating a new Colormap[1] and calling XStoreColors once (to fill the whole Colormap with exactly the colors you need) for this sort of thing. Hope that helps, Peter Harris [1] Please don't call InstallColormap - that's for window managers. Try both XSetWMColormapWindows (at the top level) and XChangeWindowAttributes (on each window and subwindow that needs the custom colormap). Yes, PseudoColor is a pain. Even more so on Windows, although that's down to taste (much like clipboards). Fortunately, PseudoColor seems to be mostly dead these days. -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Help interpreting evdev error messages?
My linux distribution (gentoo) just updated to xorg-server 1.5.3 and evdev 2.1.3. I have it almost-but-not-quite working. The keyboard works correctly AFAICT and the mouse works except for emulate-wheel, which was working before the update. I see these errors from the X server: (**) Option CorePointer (**) Mouse0: always reports core events (**) Mouse0: Device: /dev/input/mice (EE) ioctl EVIOCGBIT failed: Inappropriate ioctl for device (II) UnloadModule: evdev (EE) PreInit returned NULL for Mouse0 (**) Option CoreKeyboard (**) Keyboard0: always reports core events (EE) Keyboard0: No device specified. (II) UnloadModule: evdev (EE) PreInit returned NULL for Keyboard0 (II) config/hal: Adding input device ImExPS/2 Logitech Explorer Mouse (**) ImExPS/2 Logitech Explorer Mouse: always reports core events (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/event4 (II) ImExPS/2 Logitech Explorer Mouse: Found 5 mouse buttons **WRONG** (II) ImExPS/2 Logitech Explorer Mouse: Found x and y relative axes (II) ImExPS/2 Logitech Explorer Mouse: Configuring as mouse (**) ImExPS/2 Logitech Explorer Mouse: YAxisMapping: buttons 4 and 5 (**) ImExPS/2 Logitech Explorer Mouse: EmulateWheelButton: 4,**WRONG** EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device ImExPS/2 Logitech Explorer Mouse (type: MOUSE) (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event3 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us I have this in xorg.conf: Section InputDevice Identifier Keyboard0 Driver evdev EndSection Section InputDevice Identifier Mouse0 Driver evdev Option Protocol auto Option Device /dev/input/mice Option Emulate3Buttons True Option EmulateWheel True Option EmulateWheelButton 8 ---NOTE EndSection As you can see, EmulateWheel is broken because the button has the wrong value, I'm guessing because the evdev module was un- loaded for some reason. I have CONFIG_INPUT_EVDEV=y in my kernel config. Any idea where I'm going wrong? Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, Apr 07, 2009 at 06:39:59PM +, Tuomo Valkonen wrote: On 2009-04-07, Corbin Simpson mostawesomed...@gmail.com wrote: Pollute my system with KDE or Gnome? Rather install Windows. Sounds like a plan. Enjoy your Cleartype. Plan executed and succesfully accomplished. Byebye Linux. Windows XP has a simple option to disable blurring -- actually it isn't even enabled by default for small fonts. In Vista and W7 it's complicated, but still doable (most easily by choosing a suitable theme, although there's no longer a simple option on W7). OS X is the most fascist of them all; there is no way at all to disable blurring on it, AFAIK. -- In 1995, Linux was almost a bicycle; an alternative way of live to the Windows petrol beasts that had to be taken to the dealer for service. By 2008, Linux has bloated into a gas-guzzler, and the cycle paths have been replaced with polluted motorways. I'm glad to hear it. ISTR the msft.* newsgroups being quite good from quite some time ago: maybe you'd prefer to join them rather than your continual aimless whining on x...@. Either way, you're now moderated. Few regards, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Help interpreting evdev error messages?
On Tue, Apr 07, 2009 at 06:52:42PM -0700, walt wrote: My linux distribution (gentoo) just updated to xorg-server 1.5.3 and evdev 2.1.3. I have it almost-but-not-quite working. The keyboard works correctly AFAICT and the mouse works except for emulate-wheel, which was working before the update. I see these errors from the X server: (**) Option CorePointer (**) Mouse0: always reports core events (**) Mouse0: Device: /dev/input/mice (EE) ioctl EVIOCGBIT failed: Inappropriate ioctl for device (II) UnloadModule: evdev (EE) PreInit returned NULL for Mouse0 (**) Option CoreKeyboard (**) Keyboard0: always reports core events (EE) Keyboard0: No device specified. (II) UnloadModule: evdev (EE) PreInit returned NULL for Keyboard0 (II) config/hal: Adding input device ImExPS/2 Logitech Explorer Mouse (**) ImExPS/2 Logitech Explorer Mouse: always reports core events (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/event4 (II) ImExPS/2 Logitech Explorer Mouse: Found 5 mouse buttons **WRONG** (II) ImExPS/2 Logitech Explorer Mouse: Found x and y relative axes (II) ImExPS/2 Logitech Explorer Mouse: Configuring as mouse (**) ImExPS/2 Logitech Explorer Mouse: YAxisMapping: buttons 4 and 5 (**) ImExPS/2 Logitech Explorer Mouse: EmulateWheelButton: 4,**WRONG** EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device ImExPS/2 Logitech Explorer Mouse (type: MOUSE) (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event3 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us I have this in xorg.conf: Section InputDevice Identifier Keyboard0 Driver evdev EndSection Section InputDevice Identifier Mouse0 Driver evdev Option Protocol auto Option Device /dev/input/mice /dev/input/mice is not an evdev device, so the device fails to be set up (EE) ioctl EVIOCGBIT failed: Inappropriate ioctl for device instead, the device is picked up by the HAL configuration files which have the default settings, including the wheel emulation button on 4. Option Emulate3Buttons True Option EmulateWheel True Option EmulateWheelButton 8 ---NOTE EndSection As you can see, EmulateWheel is broken because the button has the wrong value, I'm guessing because the evdev module was un- loaded for some reason. I have CONFIG_INPUT_EVDEV=y in my kernel config. Any idea where I'm going wrong? copy /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi into /etc/hal/fdi/policy and then edit it accordingly to have a match rule against your device* (or all devices) to merge the key input.x11_options.EmulateWheelButton with the value 8. then restart HAL, verify the key actually shows up (lshal | grep x11_options should do) and restart X. Note that the /usr/share/hal/... file may be in a different location gentoo, not sure about that. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
