Bug#335071: twm should provide a session file for kdm and gdm
Package: twm Version: 6.8.2.dfsg.1-9 Severity: wishlist Hello, To make twm a selectable option in gdm and kdm (though for the moment kdm provides its own file), twm should ship /usr/share/xsessions/twm.desktop. I've attached the .desktop file from kdm, which can be modified as needed, though it seems to work in its current state. Cheers, Christopher Martin twm.desktop Description: application/desktop
Bug#237877: Patches for X.Org: dpi settings changes
Any chance that the changes I suggested below (in previous posts to this bug number) will be reviewed in time to make the 6.9.0 release upload? The problems I describe are still relevant. Let me know if I can supply any further information, or answer any questions. Thanks, Christopher Martin On May 20, 2005 11:07, Christopher Martin wrote: > These patches, for the etch-targeted X.Org server, improve dpi handling > in several ways. > > The first, fallback_dpi.patch, is a new one-line patch that changes the > xserver's final fallback dpi value from 75 to 100. I've written > extensively (to this bug report) on why this is a very important and > quite safe change that would be great to have in the X.Org packages. In > summary, since a default fallback value will always be required, we > should make it a good one. This has ramifications for the choosing of > default font sizes (in KDE, for instance). > > The other two items, 905_debian_xdm.diff.diff and xserverrc.diff, are > diffs to existing Debian patches and files. They remove the forcing of > 100 dpi on startup, when using startx or xdm. With the pending debconf > reforms, and the near-ubiquity of DDC, it no longer makes sense to force > a specific dpi value on startup as the default behaviour. In conjunction > with > fallback_dpi.patch, users for whom dpi auto-calculation fails will notice > no difference, since X would in this case fall back to 100 dpi anyway. > I've made more general arguments about dpi handling in my previous posts > to #237877. > > I'm putting forth these diffs while the X.Org packages are young and > experimental, since this is the perfect time to try these sorts of > changes. I hope you'll apply them. pgpM7SoARcwVh.pgp Description: PGP signature
Bug#343728: 097_mouse_zaxis_mapping_pushes_up_buttons should be dropped as of 6.9/7.0 RC3
Package: xserver-xorg Version: 6.8.99.903.dfsg.1-1 Severity: normal Tags: experimental Debian's X.Org packaging includes the patch 097_mouse_zaxis_mapping_pushes_up_buttons.diff, which serves to adjust mouse button mappings so that users didn't have to use xmodmap to make all available physical buttons available for use. In X.Org 6.9/7.0 RC3, upstream made changes to the mouse button handling. The default ZAxisMapping is "4 5 6 7", accommodating scroll wheels with two axes. Also by default the mouse physical : logical button mapping is now "1 2 3 8 9 ...", so that all physical buttons can be used (thumb buttons are 8 and 9) without conflict with the scroll wheel. These changes make Debian's 097 patch obsolete, since now all buttons are properly exposed by default. Indeed, continuing to include the 097 patch causes problems, since the buttons are shifted around twice, and it all becomes very messy. (When wondering why imwheel stopped working with the latest experimental X, I read up on upstream's changes, and had to rebuild X without 097 to get the expected new behaviour). FYI, since you'll probably get questions/bug reports, this change in behaviour has other implications. Mozilla uses buttons 6 and 7 for "forward" and "back", but this doesn't work anymore, since those buttons are now assumed to represent the horizontal axis of the scroll wheel, whether your mouse has one or not. Users can of course use xmodmap or the new ButtonMapping xorg.conf option to work around this. As far as I can tell, Qt applications seem to use 6 and 7 for horizontal scrolling already, so they shouldn't generate too many reports of brokenness. Cheers, Christopher Martin I'd also like to append this obligatory nag to have bug #237877 looked at :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237877: Patches for X.Org: dpi settings changes
Attached are updated patches that apply to the latest X.Org in unstable. Cheers, Christopher Martin On Sunday 06 November 2005 15:09, Christopher Martin wrote: > Any chance that the changes I suggested below (in previous posts to this > bug number) will be reviewed in time to make the 6.9.0 release upload? > The problems I describe are still relevant. Let me know if I can supply > any further information, or answer any questions. > > Thanks, > Christopher Martin > > On May 20, 2005 11:07, Christopher Martin wrote: > > These patches, for the etch-targeted X.Org server, improve dpi handling > > in several ways. > > > > The first, fallback_dpi.patch, is a new one-line patch that changes the > > xserver's final fallback dpi value from 75 to 100. I've written > > extensively (to this bug report) on why this is a very important and > > quite safe change that would be great to have in the X.Org packages. In > > summary, since a default fallback value will always be required, we > > should make it a good one. This has ramifications for the choosing of > > default font sizes (in KDE, for instance). > > > > The other two items, 905_debian_xdm.diff.diff and xserverrc.diff, are > > diffs to existing Debian patches and files. They remove the forcing of > > 100 dpi on startup, when using startx or xdm. With the pending debconf > > reforms, and the near-ubiquity of DDC, it no longer makes sense to > > force a specific dpi value on startup as the default behaviour. In > > conjunction with > > fallback_dpi.patch, users for whom dpi auto-calculation fails will > > notice no difference, since X would in this case fall back to 100 dpi > > anyway. I've made more general arguments about dpi handling in my > > previous posts to #237877. > > > > I'm putting forth these diffs while the X.Org packages are young and > > experimental, since this is the perfect time to try these sorts of > > changes. I hope you'll apply them. --- xorg.orig/debian/patches/debian/905_debian_xdm.diff +++ xorg.patched/debian/patches/debian/905_debian_xdm.diff @@ -12,8 +12,7 @@ * config/Xres.cpp: report OS name in greeter widget * config/Xserv.ws.cpp: - add comments to help local admins -- run local server with DPI setting forced to 100 and TCP listening - turned off for security +- run local server with TCP listening turned off for security * config/Xsession: replace guts with simple call to Debian's Xsession script * config/xdm-conf.cpp: @@ -124,7 +123,7 @@ +XCOMM Examples for multiple local X displays: +XCOMM :0 local BINDIR/X :0 vt9 -depth 15 -nolisten tcp +XCOMM :1 local BINDIR/X :1 vt10 -depth 8 -nolisten tcp -+:0 local BINDIR/X DEFAULTVT -dpi 100 -nolisten tcp ++:0 local BINDIR/X DEFAULTVT -nolisten tcp Index: xc/programs/xdm/config/Xsession.cpp === --- xc/programs/xdm/config/Xsession.cpp.orig 2005-12-24 16:46:49.0 -0500 --- xorg.orig/xc/programs/Xserver/hw/xfree86/common/xf86Priv.h +++ xorg.patched/xc/programs/Xserver/hw/xfree86/common/xf86Priv.h @@ -125,7 +125,7 @@ #define DEFAULT_LOG_VERBOSE 3 #endif #ifndef DEFAULT_DPI -#define DEFAULT_DPI 75 +#define DEFAULT_DPI 100 #endif #define DEFAULT_UNRESOLVED TRUE --- xorg.orig/debian/local/xserverrc +++ xorg.patched/debian/local/xserverrc @@ -2,4 +2,4 @@ # $Id: xserverrc 189 2005-06-11 00:04:27Z branden $ -exec /usr/bin/X11/X -dpi 100 -nolisten tcp +exec /usr/bin/X11/X -nolisten tcp
Bug#343728: 097_mouse_zaxis_mapping_pushes_up_buttons should be dropped as of 6.9/7.0 RC3
severity 343728 grave stop Since this patch is still included in the X.Org packaging in unstable, imwheel is now broken. Please drop the patch (made obsolete by upstream changes, as explained below) in the next upload. This link (and the links it contains) explains further: https://bugs.freedesktop.org/show_bug.cgi?id=1900 Thanks, Christopher Martin On Saturday 17 December 2005 12:14, Christopher Martin wrote: > Package: xserver-xorg > Version: 6.8.99.903.dfsg.1-1 > Severity: normal > Tags: experimental > > Debian's X.Org packaging includes the patch > 097_mouse_zaxis_mapping_pushes_up_buttons.diff, which serves to adjust > mouse button mappings so that users didn't have to use xmodmap to make > all available physical buttons available for use. > > In X.Org 6.9/7.0 RC3, upstream made changes to the mouse button handling. > The default ZAxisMapping is "4 5 6 7", accommodating scroll wheels with > two axes. Also by default the mouse physical : logical button mapping is > now "1 2 3 8 9 ...", so that all physical buttons can be used (thumb > buttons are 8 and 9) without conflict with the scroll wheel. > > These changes make Debian's 097 patch obsolete, since now all buttons are > properly exposed by default. Indeed, continuing to include the 097 patch > causes problems, since the buttons are shifted around twice, and it all > becomes very messy. (When wondering why imwheel stopped working with the > latest experimental X, I read up on upstream's changes, and had to > rebuild X without 097 to get the expected new behaviour). > > FYI, since you'll probably get questions/bug reports, this change in > behaviour has other implications. Mozilla uses buttons 6 and 7 for > "forward" and "back", but this doesn't work anymore, since those buttons > are now assumed to represent the horizontal axis of the scroll wheel, > whether your mouse has one or not. Users can of course use xmodmap or the > new ButtonMapping xorg.conf option to work around this. As far as I can > tell, Qt applications seem to use 6 and 7 for horizontal scrolling > already, so they shouldn't generate too many reports of brokenness. > > Cheers, > Christopher Martin > > I'd also like to append this obligatory nag to have bug #237877 looked at > :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#237877: X's falling back to 75 dpi
Hello, Recently I took it upon myself to adjust KDE's default fonts in the 3.4 packages targeted at post-Sarge, to make KDE more pleasant and usable "out of the box." I picked as a default size 10 points, which is same default size as used by GTK2, and on any reasonably modern display yields very readable text. However, I promptly received a number of complaints from users who found that these fonts were too small. Most, it turns out, launch KDE using a display manager, such as kdm, that does not force a certain dpi (as in xdm's 100 dpi default), and moreover for whatever reason X failed to calculate their display's true dpi, causing it to set the fallback dpi of 75. Had the correct dpi been set, most of these users would not have had an issue. More to my point, had X fallen back to a better default value, they would not have had an issue either. X's antiquated fallback of 75 dpi is thus something of an obstacle for packagers who wish to pick sensible defaults, and make Debian "just work" for most users, since we are pressured to provide defaults that work at 75 dpi, which are far too large for users of modern, properly setup displays. GNOME, interestingly, runs a settings daemon that by default sets 96 dpi for fonts on all displays. KDE does no such thing, however. To ameliorate this issue, I urge that immediately post-Sarge (pre-Sarge would be ideal, but I'd understand), whether debconf is reformed or not, Debian's X be altered to fall back to 96 dpi. Though a -softdpi switch might be nice, since both -softdpi and the current hardcoded value are fallbacks in case auto-calculation fails, from the standpoint of the end user, they are indistinguishable. True, -softdpi's fallback value could be altered, whereas what I'm proposing is to change the build-time default, but if the user needed to alter -softdpi, then they could just as easily set -dpi and get the same result. Display managers such as kdm would also have to be patched to set -softdpi. Thus while -softdpi would solve the problem, I don't think such a special switch would be worth the effort; simply changing X's fallback should be sufficient. Once this is done, and perhaps when debconf gets better at helping users set good defaults in this area, xdm/startx's forcing of 100 dpi should also be dropped (I'm in the "drop it now" camp, but I imagine that the simple addition of my name to the list won't sway you...). Why pick 96 dpi instead of 100 dpi? Obviously for a fallback the difference is not one of the utmost importance, but I feel that 96 would be better, for reasons outlined at http://scanline.ca/dpi/index.html, though there may be reasons to use 100 dpi that I'm not aware of, here in my pure TrueType world. That site makes the further proposal that X set a default system-wide Xft font default of 96 dpi; I find the idea appealing, but I realize that many people would object to it, using arguments not without merit, and so I won't push for such a change today. Thanks, Christopher Martin Please CC me on all replies and follow-ups. I'm not subscribed to debian-x. pgpuI75Q8VB1U.pgp Description: PGP signature
Bug#237877: Fwd: Bug#237877: X's falling back to 75 dpi
On May 1, 2005 08:26, you wrote: > On 22/4/2005 Cristopher Martin wrote : > > Recently I took it upon myself to adjust KDE's default fonts > > I picked as a default size 10 points, > > That is the problem. You specify fontsize in points. > And then you try to "solve" problem by setting dpi. The most obvious means at my disposal... > Trying to change default dpi for a purpose that is different from >making it more accurately represent > most common or average dpi of our user's displays, That is precisely what I suggested in my message - 96 dpi is much closer to the typical dpi of displays than 75 dpi. >amounts to you pushing a specific (wrong) interpretation of dpi, >which goes against wishes of others, >who use a different (wrong) interpretation of dpi. > This explains why you got complaints. Before this change, the complaints were that the default fonts were too large, since for most people, with correct dpi on modern displays, they were. Many users have also objected to forcing a specific dpi on them (therefore establishing a known relationship between points and pixels) and while I wouldn't mind it myself, it would have to be done either in the manner of GNOME, where users can adjust it themselves with a nice GUI, without superuser privileges, or else in the manner proposed by Mr. Biggs' article, namely an easily editable/removable setting in a global configuration file. > If K applications are not capable of specifying default font in pixels, >please fix that, >instead of trying to change X in a random unrelated way. Your arguments are very interesting, but I have a concrete problem to solve, one that can be substantially ameliorated by an almost trivial change to a specific default value in X. I realize that this change is not a perfect or complete fix to a very general problem, but I'm not about to rewrite the X/KDE font system at the moment. > That are my thoughts on this subject. > Please feel free to point out anything you think is wrong with them. I appreciate your interesting thoughts on the matter of font sizes, and I agree with many of your ideas - but they don't constitute a rebuttal of my request to have a small change to X made (and perhaps they weren't intended to, but it seems that way). You are critiquing the general font sizing system currently in use, and that is fine, but I'm interested in a smaller and easier "patch-up" for the time being. Cheers, Christopher Martin pgpi31ThoGUep.pgp Description: PGP signature
Bug#237877: Patches for X.Org: dpi settings changes
These patches, for the etch-targeted X.Org server, improve dpi handling in several ways. The first, fallback_dpi.patch, is a new one-line patch that changes the xserver's final fallback dpi value from 75 to 100. I've written extensively (to this bug report) on why this is a very important and quite safe change that would be great to have in the X.Org packages. In summary, since a default fallback value will always be required, we should make it a good one. This has ramifications for the choosing of default font sizes (in KDE, for instance). The other two items, 905_debian_xdm.diff.diff and xserverrc.diff, are diffs to existing Debian patches and files. They remove the forcing of 100 dpi on startup, when using startx or xdm. With the pending debconf reforms, and the near-ubiquity of DDC, it no longer makes sense to force a specific dpi value on startup as the default behaviour. In conjunction with fallback_dpi.patch, users for whom dpi auto-calculation fails will notice no difference, since X would in this case fall back to 100 dpi anyway. I've made more general arguments about dpi handling in my previous posts to #237877. I'm putting forth these diffs while the X.Org packages are young and experimental, since this is the perfect time to try these sorts of changes. I hope you'll apply them. Thanks, Christopher Martin --- xorg.orig/trunk/debian/patches/905_debian_xdm.diff +++ xorg.patched/trunk/debian/patches/905_debian_xdm.diff @@ -12,8 +12,7 @@ * config/Xres.cpp: report OS name in greeter widget * config/Xserv.ws.cpp: - add comments to help local admins -- run local server with DPI setting forced to 100 and TCP listening - turned off for security +- run local server with TCP listening turned off for security * config/Xsession: replace guts with simple call to Debian's Xsession script * config/xdm-conf.cpp: @@ -111,7 +110,7 @@ +XCOMM Examples for multiple local X displays: +XCOMM :0 local BINDIR/X :0 vt9 -depth 15 -nolisten tcp +XCOMM :1 local BINDIR/X :1 vt10 -depth 8 -nolisten tcp -+:0 local BINDIR/X DEFAULTVT -dpi 100 -nolisten tcp ++:0 local BINDIR/X DEFAULTVT -nolisten tcp diff -ruN xc-old/programs/xdm/config/Xsession xc/programs/xdm/config/Xsession --- xc-old/programs/xdm/config/Xsession 2004-04-23 19:54:43.0 + +++ xc/programs/xdm/config/Xsession 2004-10-27 05:41:49.532615456 + --- xc.orig/programs/Xserver/hw/xfree86/common/xf86Priv.h +++ xc.patched/programs/Xserver/hw/xfree86/common/xf86Priv.h @@ -122,7 +122,7 @@ #define DEFAULT_LOG_VERBOSE 3 #endif #ifndef DEFAULT_DPI -#define DEFAULT_DPI 75 +#define DEFAULT_DPI 100 #endif #define DEFAULT_UNRESOLVED TRUE --- xorg.orig/trunk/debian/local/xserverrc +++ xorg.patched/trunk/debian/local/xserverrc @@ -1,2 +1,2 @@ #!/bin/sh -exec /usr/bin/X11/X -dpi 100 -nolisten tcp +exec /usr/bin/X11/X -nolisten tcp
