Re: Please re-build and upload xfree86 4.3.0.dfsg.1-7
On Sun, 12 Sep 2004, Fabio Massimo Di Nitto wrote: Hi porters, a few days back xfree86 has been uploaded with urgency=high since it fixes a bunch of RC bugs. On both s390 and mips the build failed due to lack of disk space. Please take appropriate actions to complete the build and upload asap. We need to get -7 asap into sarge. Thanks Fabio Hi guys, thanks for attempting another build of X on s390, but the situation didn't change. I am pretty sure that the buildd is still lacking disk space. The main difference from -6 and -7 is that the fonts are not builded anymore and the process goes much further compared to the previous builds of X. If error reported in the log was the real error, that would have shown on all the others archs as well. Can anybody try to build it manually (like it was done in past iirc) or tell us if that error is real? Thanks Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
X Strike Force XFree86 SVN commit: r1808 - in trunk/debian: . local
Author: branden
Date: 2004-09-12 23:47:14 -0500 (Sun, 12 Sep 2004)
New Revision: 1808
Modified:
trunk/debian/CHANGESETS
trunk/debian/changelog
trunk/debian/local/Xsession
Log:
In the Xsession script, attempt to create a file of non-zero length in
/tmp; a full filesystem can cause mysterious X session failures.
Update Vim modeline.
Modified: trunk/debian/CHANGESETS
===
--- trunk/debian/CHANGESETS 2004-09-12 23:04:28 UTC (rev 1807)
+++ trunk/debian/CHANGESETS 2004-09-13 04:47:14 UTC (rev 1808)
@@ -11,4 +11,8 @@
Update Danish debconf template translations (thanks, Claus Hindsgaul)
1806
+In the Xsession script, attempt to create a file of non-zero length in
+/tmp; a full filesystem can cause mysterious X session failures.
+1808
+
vim:set ai et sts=4 sw=4 tw=80:
Modified: trunk/debian/changelog
===
--- trunk/debian/changelog 2004-09-12 23:04:28 UTC (rev 1807)
+++ trunk/debian/changelog 2004-09-13 04:47:14 UTC (rev 1808)
@@ -5,8 +5,13 @@
* Update Danish debconf template translations (thanks, Claus Hindsgaul).
(Closes: #270503)
- -- Fabio M. Di Nitto [EMAIL PROTECTED] Mon, 06 Sep 2004 15:29:56 +0200
+ Changes by Branden Robinson:
+ * In the Xsession script, attempt to create a file of non-zero length in
+/tmp; a full filesystem can cause mysterious X session failures.
+
+ -- Branden Robinson [EMAIL PROTECTED] Sun, 12 Sep 2004 23:45:07 -0500
+
xfree86 (4.3.0.dfsg.1-7) unstable; urgency=high
Changes by Branden Robinson:
Modified: trunk/debian/local/Xsession
===
--- trunk/debian/local/Xsession 2004-09-12 23:04:28 UTC (rev 1807)
+++ trunk/debian/local/Xsession 2004-09-13 04:47:14 UTC (rev 1808)
@@ -100,6 +100,18 @@
errormsg no \$SYSSESSIONDIR\ directory found; aborting.
fi
+# Attempt to create a file of non-zero length in /tmp; a full filesystem can
+# cause mysterious X session failures. We do not use touch, :, or test -w
+# because they won't actually create a file with contents. We also let
standard
+# error from tempfile and echo go to the error file to aid the user in
+# determining what went wrong.
+WRITE_TEST=$(tempfile)
+if ! echo * $WRITE_TEST; then
+ message warning: unable to write to ${WRITE_TEST%/*}; X session may exit \
+ with an error
+fi
+rm -f $WRITE_TEST
+
# use run-parts to source every file in the session directory; we source
# instead of executing so that the variables and functions defined above
# are available to the scripts, and so that they can pass variables to each
@@ -113,4 +125,4 @@
exit 0
-# vim:ai:et:sts=2:sw=2:tw=80:
+# vim:set ai et sts=2 sw=2 tw=80:
X Strike Force XFree86 SVN commit: r1809 - trunk/debian
Author: fabbione Date: 2004-09-13 01:18:48 -0500 (Mon, 13 Sep 2004) New Revision: 1809 Modified: trunk/debian/TODO Log: Add item. Modified: trunk/debian/TODO === --- trunk/debian/TODO 2004-09-13 04:47:14 UTC (rev 1808) +++ trunk/debian/TODO 2004-09-13 06:18:48 UTC (rev 1809) @@ -17,6 +17,9 @@ 4.3.0.dfsg.1-8 -- +* Fix for the nv driver breakage, consider backporting the driver from + x.org. + See: #269025, #268759, #271235, #270228, #271071 * Add FAQ entry describing what has become of the XFree86 3.x packages. * Rewrite xserver-xfree86 debconfage. Joey Hess, Eduard Bloch, and David Nusinow have provided good input.
X Strike Force XFree86 SVN commit: r1810 - branches/debconf-overhaul/debian
Author: fabbione Date: 2004-09-13 01:28:59 -0500 (Mon, 13 Sep 2004) New Revision: 1810 Modified: branches/debconf-overhaul/debian/xserver-xfree86.config.in Log: Make fb_type detection more flexible. Test case reported: fb_type=OFfb NVDA,NVMac would set the use of fb to true. Hardware: ppc with nvidia gfx. Modified: branches/debconf-overhaul/debian/xserver-xfree86.config.in === --- branches/debconf-overhaul/debian/xserver-xfree86.config.in 2004-09-13 06:18:48 UTC (rev 1809) +++ branches/debconf-overhaul/debian/xserver-xfree86.config.in 2004-09-13 06:28:59 UTC (rev 1810) @@ -953,16 +953,13 @@ # did we actually get back anything? if [ -n $fb_type ]; then set_db_priority medium -case $fb_type in - OFfb|VESA) -trace $func(): this framebuffer type does not support UseFBDev -default_use_fbdev=false -;; - *) -# other framebuffers do support UseFBDev -default_use_fbdev=true -;; -esac +if echo $fb_type | grep -Eiq '(OFfb|VESA)'; then + trace $func(): this framebuffer type does not support UseFBDev + default_use_fbdev=false +else + # other framebuffers do support UseFBDev + default_use_fbdev=true +fi fi else trace $func(): /proc/fb does not exist; assuming fbcon not in use
Bug#271235: xserver-xfree86: [nv] XVideo fails silently (but visually) in mplayer
I'm experiencing this bug too with the same xserver-xfree86 version (4.3.0.dfsg.1-7) on the same configuration (NVidia GeForce2 MX400, nv driver which comes with XFree86). MPlayer doesn't show the video and tvtime (which also uses the XVideo extension) misbehaves too. The image shows, but it doesn't redraw areas previously covered by other windows and in full screen mode only a part of the image is displayed). There are no error messages in the XFree86 log, nor MPlayer nor tvtime display any. signature.asc Description: OpenPGP digital signature
Re: [XFree86] Re: x(dm) freezes at first start
On 12/09/2004 Michel Dänzer wrote: On Sat, 2004-09-11 at 14:21 +0200, Jonas Meurer wrote: at boot, when xdm is started, x freezes directly after the login screen is displayed. sometimes it's possible to type in the login name, but at the latest at typing the password, the complete screen freezes. FWIW, I used to see something similar with gdm and kdm a while back, and it was a VT allocation race between the X server and the gettys. IIRC the X server would attach to VT 2 but display on VT 7, so it would never get the input. AFAIR the mouse cursor worked though, is that the case for you? exactly, the mouse cursor still works, only keyboard seems to be broken. after hitting alt+sysrq+k, the screen get's messed up, then i change to tty1, this vc gets messed up completely, i type '/etc/init.d/xdm stop', and the messed up screen becomes somehow reset. bye jonas
Re: Please re-build and upload xfree86 4.3.0.dfsg.1-7
Fabio Massimo Di Nitto wrote: Hi guys, thanks for attempting another build of X on s390, but the situation didn't change. I am pretty sure that the buildd is still lacking disk space. The main difference from -6 and -7 is that the fonts are not builded anymore and the process goes much further compared to the previous builds of X. If error reported in the log was the real error, that would have shown on all the others archs as well. Can anybody try to build it manually (like it was done in past iirc) or tell us if that error is real? I am getting the same error when building it manually. The doc directory doesn't exist. Gerhard
Microsoft disc ounts
Corel Draw Graphics Suite 11 - 120.00 Microsoft Windows 2000 Server - 50.00 Mc Afee SpamKiller 2004 - 20.00 Adobe Photoshop CS - 80.00 Adobe Photoshop 7.0 - 60.00 Abode InDesign CS - 100.00 Easy CD DVD Creator 6 - 29.99 Norton Antivirus 2004 Professional Edition - 15.00 Ahead Nero v6.3 Powerpack - 40.00 Adobe InCopy CS - 60.00 Linux RedHat 7.3 - 60.00 Quark Express 6.0 - 60.00 Adobe Acrobat 6.0 Professional - 100.00 Mc Afee SpamKiller 2004 - 20.00 and more http://www.hotoem.info/
Bug#271499: xfonts-base-transcoded: fontconfig error Cannot load default config file during configuration
Package: xfonts-base-transcoded Version: 4.3.0.dfsg.1-4 Severity: normal I installed x-window-system-core and all the xfonts-*-transcoded packages via one single apt-get install command. During the configuration of the xfonts-*-transcoded packages (I'm not really sure if it were exactly these packages.), I got the following error message: Fontconfig error: Cannot load default config file Obviously, fontconfig wasn't configured yet. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Kernel: Linux 2.4.18-bf2.4 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xfonts-base-transcoded depends on: ii xutils4.3.0.dfsg.1-4 X Window System utility programs -- no debconf information
Bug#261993: Probably X bug
[The following is a form letter.] Dear bug submitter, Since the XFree86 X server is a large and complex piece of software, some more information is required of you before this bug can be handled. Please run the following commands from a shell prompt to gather and deliver this information to us: $ /usr/share/bug/xserver-xfree86 /tmp/output 31 $ mailx -s Re: Bug#261993 [EMAIL PROTECTED] /tmp/output If you do not have a mailx command on your system, you can get it by installing the mailx Debian package; for example, with the aptitude install mailx or apt-get install mailx commands as root. Alternatively, you can also use a mail command that is compatible with mailx's command-line syntax, such as mutt. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. The reportbug program does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System in the future. If you *did* use reportbug to file your report, then you're receiving this message because the information we expected to see was not present. If you deliberately deleted this information from the report, please don't do that in the future, even if it seems like it makes the mail too large. 50 kB (kilobytes) of configuration and log data is typical. Only if the included information greatly exceeds this amount (more than 100 kB) should you consider omitting it; instead, put it up on the World Wide Web somewhere and provide URLs to it in your report, or in subsequent followup by mailing [EMAIL PROTECTED]. Thank you! -- G. Branden Robinson| I'm not going to waste my precious Debian GNU/Linux | flash memory with Perl when I can [EMAIL PROTECTED] | do so much more with it. http://people.debian.org/~branden/ | -- Joey Hess signature.asc Description: Digital signature
Processed: severity of 264016 is wishlist, merging 264016 264017
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.4 severity 264016 wishlist Bug#264016: fvwm: FvwmForm uses bad fonts in utf-8 locale Severity set to `wishlist'. # let's not swipe the ball away like Lucy when Charlie Manoj Brown tries to kick it merge 264016 264017 Bug#264016: fvwm: FvwmForm uses bad fonts in utf-8 locale Bug#264017: xfonts-base: don't hard-code iso8859-1 in short aliases, eg fixed Merged 264016 264017. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#263952: Pointers and Scale are invisible on secondary XINERAMA screens
On Wed, Sep 01, 2004 at 12:19:42PM +0200, Jan-Benedict Glaw wrote: [...] No problem to provide more info. Unfortunately, I'm currently in my holidays and don't have physical access to the machine. However, I can tell you about the config. [...] That needs physical access, so I can do that somewhen at/after upcoming monday. [...] That's it for now. I'll do the real tests most probably on monday. Any progress on this? -- G. Branden Robinson| If atheism is a religion, then Debian GNU/Linux | health is a disease. [EMAIL PROTECTED] | -- Clark Adams http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#263952: Pointers and Scale are invisible on secondary XINERAMA screens
On Sun, Sep 05, 2004 at 10:46:31PM -0400, Michel Dänzer wrote: Actually, I'd expect a driver rendering bug to be captured in the framebuffer and consequently on screen captures. If the bug lies in the server, I don't think you can tell where exactly from the client side. Ah. Thanks (as usual :) ) for correcting my busted notion of how the X server draws things. :) -- G. Branden Robinson| There's something wrong if you're Debian GNU/Linux | always right. [EMAIL PROTECTED] | -- Glasow's Law http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
On Wed, Sep 01, 2004 at 11:38:16AM -0400, Jay Berkenbilt wrote: On Mon, Aug 02, 2004 at 08:57:50PM -0400, Jay Berkenbilt wrote: I truly hope you will consider including this simple patch in time for sarge. I think it will really improve the way people's X displays will look and help to make Debian a better distribution. :-) I decided a long time ago to include it; please see the TODO file for the XFree86 package and its Subversion history. http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/TODO Thanks for the information and the pointer. Do you think 4.3.0.dfsg.1-7 will be in sarge? Feel free to not answer if you think it's a stupid question. ;-) (I'm following traffic on debian-devel and debian-release, so I know about the autobuilder issues, moving freeze date, etc.) The X Strike Force, including Fabio Massimo Di Nitto (our XFree86 package release manager) and myself are trying to see to it that 4.3.0.dfsg.1-8 makes it into sarge. Some changes for -7 were deferred to -8 due to the massive number of changes in -7. -- G. Branden Robinson|Somebody once asked me if I thought Debian GNU/Linux |sex was dirty. I said, It is if [EMAIL PROTECTED] |you're doing it right. http://people.debian.org/~branden/ |-- Woody Allen signature.asc Description: Digital signature
Processed: Re: [ati/atimisc] DoS attack possible when viewing absurdly huge fonts on Mach64 GT rev 65
Processing commands for [EMAIL PROTECTED]: tag 149631 + unreproducible Bug#149631: xserver-xfree86: [ati/atimisc] DoS attack possible when viewing absurdly huge fonts on Mach64 GT rev 65 Tags were: upstream security Tags added: unreproducible thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: r1811 - in trunk/debian: . scripts
Author: branden Date: 2004-09-13 13:58:32 -0500 (Mon, 13 Sep 2004) New Revision: 1811 Modified: trunk/debian/CHANGESETS trunk/debian/scripts/locale-munger Log: (cosmetic) Fix typo in debugging message. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-13 06:28:59 UTC (rev 1810) +++ trunk/debian/CHANGESETS 2004-09-13 18:58:32 UTC (rev 1811) @@ -8,6 +8,9 @@ (It should always be safe to merge the latest version of TODO or CHANGESETS files anywhere.) +Miscellaneous cosmetic fixes. +1811 + Update Danish debconf template translations (thanks, Claus Hindsgaul) 1806 Modified: trunk/debian/scripts/locale-munger === --- trunk/debian/scripts/locale-munger 2004-09-13 06:28:59 UTC (rev 1810) +++ trunk/debian/scripts/locale-munger 2004-09-13 18:58:32 UTC (rev 1811) @@ -221,7 +221,7 @@ print ERROR: X11 does not support glibc locale %s % (locale,) else: if RUNTIME_DEBUG: -print GOOD NEWS: X111 supports glibc locale %s % (locale,) +print GOOD NEWS: X11 supports glibc locale %s % (locale,) # Now see if locale values that include an explicit (but redundant) character # set are supported by X11.
X Strike Force XFree86 SVN commit: r1812 - in trunk/debian: . local
Author: branden Date: 2004-09-13 14:10:51 -0500 (Mon, 13 Sep 2004) New Revision: 1812 Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: (cosmetic) Add missing markup. Modified: trunk/debian/CHANGESETS === --- trunk/debian/CHANGESETS 2004-09-13 18:58:32 UTC (rev 1811) +++ trunk/debian/CHANGESETS 2004-09-13 19:10:51 UTC (rev 1812) @@ -9,7 +9,7 @@ files anywhere.) Miscellaneous cosmetic fixes. -1811 +1811, 1812 Update Danish debconf template translations (thanks, Claus Hindsgaul) 1806 Modified: trunk/debian/local/FAQ.xhtml === --- trunk/debian/local/FAQ.xhtml2004-09-13 18:58:32 UTC (rev 1811) +++ trunk/debian/local/FAQ.xhtml2004-09-13 19:10:51 UTC (rev 1812) @@ -1073,18 +1073,22 @@ a getty on VC 7./p pIf you have increased your number of virtual consoles, or otherwise require VC -7 for some purpose, simply edit /etc/X11/xdm/Xservers and change the vt7 -argument on the :0 server line to whatever VC is appropriate for your -machine (vt8, vt12, etc.). Note that while the XFree86 manual page says that -if the vt argument is not specified, the X server will use the first -available virtual console, it is not a good idea to omit this parameter when -starting local X servers with xdm. This is because even though xdm starts at -the very end of the init sequence, well after the getty processes that manage -the virtual consoles, some machines get through the init sequence so quickly -that getty has not yet claimed its VC's before xdm starts. This leads to -exactly the same kind of console lockup you get as if you deliberately tell -getty (via /etc/inittab) and xdm (via /etc/X11/xdm/Xservers) to use the same -virtual console for their respective tasks./p +7 for some purpose, simply edit code +class=filespec/etc/X11/xdm/Xservers/code and change the vt7 argument on +the :0 server line to whatever VC is appropriate for your machine (vt8, vt12, +etc.). Note that while the XFree86 manual page says that if the vt argument +is not specified, the X server will use the first available virtual console, it +is not a good idea to omit this parameter when starting local X servers with +xdm. This is because even though code class=commandxdm/code starts at the +very end of the code class=commandinit/code sequence, well after the code +class=commandgetty/code processes that manage the virtual consoles, some +machines get through the init sequence so quickly that getty has not yet claimed +its VC's before code class=commandxdm/code starts. This leads to exactly +the same kind of console lockup you get as if you deliberately tell code +class=commandgetty/code (via code class=filespec/etc/inittab/code) +and code class=commandxdm/code (via code +class=filespec/etc/X11/xdm/Xservers/code) to use the same virtual console +for their respective tasks./p h3a id=xclientasrootHow do I run an X client as root when the X session is run by a user?/a/h3 @@ -1371,22 +1375,23 @@ internally./li liWhatever is running in the code class=commandxterm/code (like the shell) can be getting bogus information from the terminfo file for the - terminal type that xterm is using. If your varTERM/var environment - variable is not set to code class=otherxterm/code, make sure you - understand why./li + terminal type that code class=commandxterm/code is using. If your + varTERM/var environment variable is not set to code + class=otherxterm/code, make sure you understand why./li liIf you still haven't found satisfaction, you may have run up against the stone wall that is inherent in emulation./li /ul -pFor some keys, due to frustrating historical practice, there is simply -going to be incompatibility with the Linux console. Why? Because xterm -was initially written to emulate a DEC VT100 terminal. PC keyboards have many -more keys than a VT100. The PC keyboard resembles a VT220 keyboard much -more closely. That's why Linus Torvalds based the kernel console driver on -VT220 emulation. If you want xterm to behave more like the Linux console, -use the terminal type code class=otherxterm-vt220/code. What keys are -affected by this historical incompatibility, and how do DEC VT220 and PC -keyboards differ? A lengthy explanation follows./p +pFor some keys, due to frustrating historical practice, there is simply going +to be incompatibility with the Linux console. Why? Because code +class=commandxterm/code was initially written to emulate a DEC VT100 +terminal. PC keyboards have many more keys than a VT100. The PC keyboard +resembles a VT220 keyboard much more closely. That's why Linus Torvalds based +the kernel console driver on VT220 emulation. If you want code +class=commandxterm/code to behave more like the Linux console, use the +terminal type code class=otherxterm-vt220/code. What keys are affected by +this historical
Bug#229850: DEFAULT_HORIZ_SYNC and DEFAULT_VERT_REFRESH still ignored (updated patch)
The X Strike Force, including Fabio Massimo Di Nitto (our XFree86 package release manager) and myself are trying to see to it that 4.3.0.dfsg.1-8 makes it into sarge. Some changes for -7 were deferred to -8 due to the massive number of changes in -7. Thanks for the update, and for mentioning trying to get -8 into Sarge. I noticed that the bug wasn't fixed for -7 and that it had been pushed to -8 in the to do list along with several other debconf changes. If you're interested in help with testing, please let me know and I'll see what I can do. Thanks for all you do and for finding the time to keep me informed through all of it. -- Jay Berkenbilt [EMAIL PROTECTED] http://www.ql.org/q/
Bug#263073: xlibs: Super still Super+Hyper
On Mon, Sep 13, 2004 at 09:03:46AM +0200, Christian Marillat wrote:
[EMAIL PROTECTED] (Denis Barbier) writes:
On Sun, Sep 12, 2004 at 07:57:56PM +, Tim Bagot wrote:
[...]
Sawfish maintainer, do you believe that this bug should be cloned and
reassigned to sawfish?
No I don't think thi is a bug in sawfish (never seen this problem
before, never reported and this work with my keyboard) i think the
problem come from GNOME which modify the keyborad layout without asking
something to users.
See bugs #250814, #251116, #251126, #251127, #251168, #251406,
#251542,#245848, #242932
Should be fixed soon...
Tim could you try to reconfigure your keyboard in the control center ?
Keyborad icon and layouts tab.
Denis if you reassign this bug to the capplets package change the
severity to important nad merge with others bugs.
Christian, thanks for your reply, but I believe that sawfish will still
have trouble when capplets is fixed. The attached test-sawfish-mods.c
file helped me to understand how sawfish (and emacs) manage modifiers.
It is copied from src/keys.c
$ setxkbmap -layout us -model pc105 -option
$ ./test-sawfish-mods
Keysym Alt_L column: 0 keycode=0x40 pos: 0
Keysym Meta_L column: 0 keycode=0x40 pos: 1
Keysym Alt_L column: 1 keycode=0x7d pos: 1
Keysym Meta_L column: 2 keycode=0x9c pos: 1
Keysym Num_Lock column: 0 keycode=0x4d pos: 0
Keysym Super_L column: 0 keycode=0x7f pos: 1
Keysym Hyper_L column: 1 keycode=0x80 pos: 1
Up to 4 symbols per modifier
alt_mod=8
meta_mod=8
super_mod=64
hyper_mod=64
The 2 last lines are important, they show that the direct_modifiers
function (also in src/keys.c) won't catch Super_* modifiers because
it contains:
if (hyper_mod != 0 (mods EV_MOD_HYPER))
mods = (mods ~EV_MOD_HYPER) | hyper_mod;
if (super_mod != 0 (mods EV_MOD_SUPER))
mods = (mods ~EV_MOD_SUPER) | super_mod;
As hyper_mod is equal to super_mod, the mods variable is modified after
the first test and the second test fails. And this is indeed what I
observed: if you set binding modifier to Super, tabbing does not work,
but it works when set to Hyper with this X setting and also with
altwin:super_win option.
Some people claim that Super and Hyper should not be bound to the same
modifier to be ICCCM-compliant, but here is the relevant part from this
spec:
Clients should determine the meaning of a modifier bit from the
KeySyms being used to control it.
They argue that the current 'us' default breaks this rule, and at the
same time add tricks to work around problems in their implementation
when Alt and Meta are bound to the same modifier.
The other point of view is that this sentence only tells that applications
should not hardcode mod1-5 but use KeySyms instead.
My previous patch discards keysyms when it is a fake key (ie. no
symbol is found at position 0). It should work quite well, but a
better fix is to let XKB query modifiers when XKB is in use, I
will try this path.
Denis
#include stdio.h
#include X11/Xlib.h
#include X11/keysym.h
#define PRINT(s) fprintf(stderr, Keysym %s column: %d keycode=0x%x pos: %d\n, \
s, col, code, code_col)
/* Copied from sawfish/src/keys.c (find_meta)
Compile with:
gcc -Wall -o test-sawfish-mods test-sawfish-mods.c \
-I/usr/X11R6/include -L /usr/X11R6/lib -lX11
*/
int
main(void)
{
Display *display = XOpenDisplay(:0);
int min_code, max_code;
KeySym *syms;
int syms_per_code;
XModifierKeymap *mods;
unsigned int num_lock_mod, scroll_lock_mod;
unsigned int meta_mod, alt_mod, hyper_mod, super_mod;
meta_mod = alt_mod = hyper_mod = super_mod = 0;
num_lock_mod = scroll_lock_mod = 0;
XDisplayKeycodes (display, min_code, max_code);
syms = XGetKeyboardMapping (display, min_code, max_code - min_code + 1,
syms_per_code);
mods = XGetModifierMapping (display);
{
int row, col;
for (row = 3; row 8; row++)
{
for (col = 0; col mods-max_keypermod; col++)
{
int code_col;
KeyCode code = mods-modifiermap[(row * mods-max_keypermod)
+ col];
if (code == 0)
continue;
for (code_col = 0; code_col syms_per_code; code_col++)
{
int sym = syms[((code - min_code) * syms_per_code)
+ code_col];
switch (sym)
{
case XK_Meta_L:
meta_mod = 1 row;
PRINT(Meta_L);
break;
case XK_Meta_R:
meta_mod = 1 row;
PRINT(Meta_R);
break;
case XK_Alt_L:
alt_mod = 1 row;
Bug#263073: xlibs: Super still Super+Hyper
[EMAIL PROTECTED] (Denis Barbier) writes: On Mon, Sep 13, 2004 at 09:03:46AM +0200, Christian Marillat wrote: [EMAIL PROTECTED] (Denis Barbier) writes: [...] Christian, thanks for your reply, but I believe that sawfish will still have trouble when capplets is fixed. The attached test-sawfish-mods.c file helped me to understand how sawfish (and emacs) manage modifiers. It is copied from src/keys.c Frankly you need to understand that sawfish is dead. So I'm just fixing important bug report and this one is not an important bug report. So you can do what you want with this bug report I'll simply ignore this bug. Christian
Bug#253607: #253607: xserver-xfree86: (debconf) X 4.3.0 is perfectly capable of detecting monitor resolutions, debconf should ask only if needed
On Mon, Sep 13, 2004 at 12:51:30PM -0500, Branden Robinson wrote: On Tue, Aug 31, 2004 at 08:13:23PM -0700, Daniel Stone wrote: On Tue, Aug 31, 2004 at 02:32:49PM -0500, Branden Robinson wrote: My only concern about that approach is we'd better be damn sure starting X doesn't lock up people's machines, especially on our more exotic architectures. discover and mdetect don't, and read-edid only seems to hurt x86 users with buggy hardware. If you have an i855 or such, try running 'X :1 -probeonly -ac' some day, when you have an X session already running. I don't own any x86 hardware and do not have access to a box with this chipset. Please describe what happens when this is done. Your current X session dies, and there's a kernel message from the DRM module about how it tried to allocate 64MB of ram and only got 58, or such. Doing a simple DDC probe doesn't seem to do any damage. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Bug#24192: old books
Dear Dr. Boggs, I purchased some early printed books in Florida with a bookplate of Ralph Boggs. I was wondering if they were from your family , and if so, if you have any others. I am a dealer in rare books from Israel. I await your kind reply. Thank you, Adam Weinberger
Bug#271599: defaults to wrong video card driver
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-7 Severity: wishlist The Select the desired X server driver question defaults to vesa, but when X starts (via gdm), it displays a blank, black screen. When I reconfigure X to use the i810 driver, it displays the gdm login dialog. The card appears to be detected by discover: $ discover --version discover version 1.6.6 $ discover --disable=serial,parallel --format=%V %M\t%S\t%D\n video Intel Corporation 82815 CGC [Chipset Graphics Controller] XFree86 i810 -- Matt Kraai[EMAIL PROTECTED]http://ftbfs.org/ signature.asc Description: Digital signature
Bug#271485: xlibosmesa-dev: No manual pages or any other info
Package: xlibosmesa-dev Version: 4.3.0.dfsg.1-4 Severity: normal I didn't found information about OSMEsaCreateContext and othe offscreen stuff in this package or other mesa and gl development packages. I saw description of off-screen rendering, it comes with Mesa tarballs, perhaps in form of README file, and i think it should be somewhere around osmesa-dev packages in Debian. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-386 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R Versions of packages xlibosmesa-dev depends on: ii libc6-dev [libc-dev] 2.3.2.ds1-13 GNU C Library: Development Librari ii mesag-dev [libgl-dev] 5.0.0-5.1 Development library for Mesa ii xlibosmesa4 4.3.0.dfsg.1-4 Mesa off-screen rendering library -- no debconf information
Bug#271525: xserver-xfree86: Modes should have default depending upon mode-list
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-7 Severity: normal I selected 1024 x 768 @ 75hz from the mode list, but in the next question (xserver-xfree86/config/display/modes), only 800x600 and 640x480 were checked. I think it would be nice if the highest resolution were checked automatically depending on our choice to the monitor question. -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. X server symlink status: lrwxrwxrwx 1 root root 20 2004-09-13 18:39 /etc/X11/X - /usr/bin/X11/XFree86 -rwxr-xr-x 1 root root 1745484 2004-09-06 13:16 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266] /var/lib/xfree86/XF86Config-4.md5sum does not exist. XFree86 X server configuration file status: -rw-r--r-- 1 root root 3667 2004-09-13 17:58 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type man XF86Config-4 at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files #FontPath unix/:7100# local font server # if the local font server has problems, we can fall back on these FontPath/usr/lib/X11/fonts/misc:unscaled FontPath/usr/lib/X11/fonts/100dpi:unscaled FontPath/usr/lib/X11/fonts/75dpi:unscaled FontPath/usr/lib/X11/fonts/truetype FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/CID FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/misc FontPath/usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi FontPath/usr/lib/X11/fonts/75dpi EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout fr EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/psaux Option Protocol PS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 Option Emulate3Buttons true Option ZAxisMapping 4 5 EndSection Section Device Identifier Savage Driver savage Option UseBIOS false EndSection Section Device Identifier Savage TV Driver savage EndSection Section Monitor Identifier LCD HorizSync 30-57 VertRefresh 43-72 Option DPMS EndSection Section Screen Identifier Default Screen Device Savage Monitor LCD DefaultDepth24 SubSection Display Depth 8 Modes 1024x768 800x600 EndSubSection SubSection Display Depth 16 Virtual 1024 768 Modes 1024x768i 800x600 EndSubSection SubSection Display Depth 24 Virtual 1024 768 Modes 1024x768 800x600 EndSubSection EndSection Section Screen Identifier TV Screen Device Savage TV Monitor LCD DefaultDepth24
Bug#271542: xlibs: Can't get Meta and Alt to work correctly
Package: xlibs Version: 4.3.0.dfsg.1-7 Severity: normal In continuation of my message in bug 256706. As it has been declared fixed, but I still suffer keyboard problems, I suppose my problem is _not_ the one of this bug. Behaviour has changed since -6, but is still not correct. I have a Microsoft Natural Keyboard, US qwerty. That's a qwerty 104 keys keyboard. Intended behaviour: Alt keys are Alt, left waving flag key is Meta, right waving flag key is compose (Multi_key), menu key is menu. XKB config: Section InputDevice Identifier Generic Keyboard Driver keyboard Option CoreKeyboard Option XkbRules xfree86 Option XkbModel microsoft Option XkbLayout us Option XkbOptionsaltwin:left_meta_win,compose:rwin EndSection When starting up X, the following behaviour happens: - Emacs does not recognise Meta as Meta, but recognises Alt as Meta, which it shouldn't. Note that if I remember well, Emacs automatically treats Alt as Meta if it thinks the current keymap does not have a Meta. This might be what is happening. - TeXmacs recognises Alt as Alt, but not Meta. - sawfish does not recognise Alt as Alt, but recognises Meta as Meta. Which makes me very confused as to what could be wrong. At startup: [EMAIL PROTECTED]:~$ xmodmap xmodmap: up to 5 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Alt_L (0x7d) mod2Num_Lock (0x4d) mod3 mod4Alt_R (0x71), Meta_L (0x73), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Trying to correct it manually: [EMAIL PROTECTED]:~$ xmodmap -e 'clear mod1' [EMAIL PROTECTED]:~$ xmodmap -e 'add mod1 = 0x73' [EMAIL PROTECTED]:~$ xmodmap xmodmap: up to 5 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1s (0x27) mod2Num_Lock (0x4d) mod3 mod4Alt_R (0x71), Meta_L (0x73), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Oups... It shouldn't say 0x27 for mod1, I said 0x73. Let's try another way: [EMAIL PROTECTED]:~$ xmodmap -e 'clear mod1' [EMAIL PROTECTED]:~$ xmodmap -e 'add mod1 = Meta_L' [EMAIL PROTECTED]:~$ xmodmap xmodmap: up to 5 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1Alt_L (0x40), Meta_L (0x73), Meta_L (0x9c) mod2Num_Lock (0x4d) mod3 mod4Alt_R (0x71), Meta_L (0x73), Super_L (0x7f), Hyper_L (0x80), Meta_L (0x9c) mod5Mode_switch (0x5d), ISO_Level3_Shift (0x7c) Not what I asked for. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.5-64bit Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xlibs depends on: ii libice6 4.3.0.dfsg.1-7 Inter-Client Exchange library ii libsm64.3.0.dfsg.1-7 X Window System Session Management ii libx11-6 4.3.0.dfsg.1-7 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-7 X Window System miscellaneous exte ii libxft1 4.3.0.dfsg.1-7 FreeType-based font drawing librar ii libxi64.3.0.dfsg.1-7 X Window System Input extension li ii libxmu6 4.3.0.dfsg.1-7 X Window System miscellaneous util ii libxmuu1 4.3.0.dfsg.1-7 lightweight X Window System miscel ii libxp64.3.0.dfsg.1-7 X Window System printing extension ii libxpm4 4.3.0.dfsg.1-7 X pixmap library ii libxrandr24.3.0.dfsg.1-7 X Window System Resize, Rotate and ii libxt64.3.0.dfsg.1-7 X Toolkit Intrinsics ii libxtrap6 4.3.0.dfsg.1-7 X Window System protocol-trapping ii libxtst6 4.3.0.dfsg.1-7 X Window System event recording an ii xlibs-data4.3.0.dfsg.1-7 X Window System client data -- no debconf information
Bug#253607: #253607: xserver-xfree86: (debconf) X 4.3.0 is perfectly capable of detecting monitor resolutions, debconf should ask only if needed
On Tue, Aug 31, 2004 at 08:13:23PM -0700, Daniel Stone wrote: On Tue, Aug 31, 2004 at 02:32:49PM -0500, Branden Robinson wrote: My only concern about that approach is we'd better be damn sure starting X doesn't lock up people's machines, especially on our more exotic architectures. discover and mdetect don't, and read-edid only seems to hurt x86 users with buggy hardware. If you have an i855 or such, try running 'X :1 -probeonly -ac' some day, when you have an X session already running. I don't own any x86 hardware and do not have access to a box with this chipset. Please describe what happens when this is done. -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire signature.asc Description: Digital signature
Bug#253607: #253607: xserver-xfree86: (debconf) X 4.3.0 is perfectly capable of detecting monitor resolutions, debconf should ask only if needed
On Tue, Aug 31, 2004 at 08:12:07PM -0700, Daniel Stone wrote: On Tue, Aug 31, 2004 at 02:32:49PM -0500, Branden Robinson wrote: Yes, somehow. You don't provide any code, or anything beyond the barest sketch of a design really, so this is going to have to wait until after sarge. http://www.google.com/search?q=ddcprobe+source This comment is too terse to be useful for me. The top link is a set of compiled RPMs for Caldera machines. In reviewing a Red Hat Bugzilla entry farther down the list, I see that ddcprobe may have as many problems as read-edid. Perhaps just different ones. :-P -- G. Branden Robinson| The noble soul has reverence for Debian GNU/Linux | itself. [EMAIL PROTECTED] | -- Friedrich Nietzsche http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Bug#11147: Fw: corbel
Do you remember when I was telling you about that link I received? http://www.blueinternetzone.com/ref44.html You can download dvd movies, full cd albums and stuff. Even console video games. So I've downloaded 5 video games movies so far today :). I can't wait untill you get a load of this selection of games music movies - it's nuts. Theres this awsome section of the site that shows you how to burn the games music and movies to CD. I'm having a quick bite to eat going overthe movie section at the moment, theres downloads in here to burn, movies I mean, that are still in theaters - talk about awsome. I'll talk to you soon. Milagros
Bug#263073: xlibs: Super still Super+Hyper
[EMAIL PROTECTED] (Denis Barbier) writes: On Sun, Sep 12, 2004 at 07:57:56PM +, Tim Bagot wrote: [...] Sawfish maintainer, do you believe that this bug should be cloned and reassigned to sawfish? No I don't think thi is a bug in sawfish (never seen this problem before, never reported and this work with my keyboard) i think the problem come from GNOME which modify the keyborad layout without asking something to users. See bugs #250814, #251116, #251126, #251127, #251168, #251406, #251542,#245848, #242932 Should be fixed soon... Tim could you try to reconfigure your keyboard in the control center ? Keyborad icon and layouts tab. Denis if you reassign this bug to the capplets package change the severity to important nad merge with others bugs. Christian
Bug#271235: I can confirm this problem
I just wondered why mozilla-mplayer was not working anymore and found also that the xv in vo line was the cause of it. -- eric
Bug#271439: xlibmesa-gl: OpenGL apps. freeze when resuming.
Package: xlibmesa-gl Version: 4.3.0.dfsg.1-4 Severity: important After I suspend/resume $ glxinfo | grep -i rendering direct rendering: Yes But glxgears and any other OpenGL apps freeze. i810 driver -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686-Uniball-1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 Versions of packages xlibmesa-gl depends on: ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an ii libxext6 4.3.0.dfsg.1-4 X Window System miscellaneous exte ii xlibs 4.3.0.dfsg.1-4 X Window System client libraries m -- no debconf information -- -- Katoob Main Developer Linux registered user #224950, ICQ #58475622 -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.fsf.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM/IT d-(++)@ s+(++):-+++ a-- C+++$ UL+++$ P+++$+ L+++()$+ E+++ W++?$ N o? K-? !w++ !O !M !V !PS@ !PE@ Y+ PGP=+++ t? 5? !X R? tv-- b+@ DI D+ G-- e+ h--++ !r y? --END GEEK CODE BLOCK-- signature.asc Description: Digital signature
Bug#263073: xlibs: Super still Super+Hyper
Christian Marillat [EMAIL PROTECTED] writes: Tim could you try to reconfigure your keyboard in the control center ? Keyborad icon and layouts tab. The layout is set correctly (generic 105-key, UK). There were no layout options selected. Adding Super is mapped to the Win-keys (default). didn't seem to do anything. I see the problem with Emacs if I run it in a bare second X session. Would it be worth my trying the same with Sawfish? Tim Bagot
Bug#270810: capplets: gnome-keyboard-properties does not load us_intl
On Sun, 12 Sep 2004, Denis Barbier wrote: reassign 270810 xlibs tags 270810 - l10n clone 270810 -1 severity 270810 normal retitle 270810 /etc/X11/xkb/rules/xfree86 does not list all old layout files severity -1 wishlist retitle -1 Please add a multi-layout version of us_intl thanks Stefan Kluth wrote: The gnome keyboard preferences panel, accessed through the keyboard indicator applet, does not manage to load us_intl as keyboard layout. Instead, a error report window pops up, but the content is not helpful. Please discard my previous comments, I had a closer look to this issue and found that: a. XFree86 upstream introduced a multi-layout version of us_intl after 4.3.0 b. Some old layout keymaps are not listed in /etc/X11/xkb/rules/xfree86 For these reasons, I reassign this bugreport to xlibs, and will provide patches for both issues very soon. Thanks a lot for your efforts ... I almost expected that capplets keyboard indicator was not to blame and I was shooting the messenger but I don't know the system well enough to be able to track this down. Cheers, Stefan ---Stefan Kluth, PhD--Wissenschaftlicher Mitarbeiter--- - MPI fuer Physik - phone: +49 89 32354 468 - OPAL - - Foehringer Ring 6 - fax:+49 89 32354 305 - ATLAS - ---D-80805 Munich, Germanye-mail: [EMAIL PROTECTED]
