Bug#492404: Acknowledgement (xserver-xorg-video-openchrome: Resolutions only up to 800x600)
Unfortunately I won't have time for further investigation until this week-end. I will try a fresh install and tell if the problem stays in latest lenny. THX Mathieu Original-Nachricht > Datum: Fri, 25 Jul 2008 20:06:04 + > Von: [EMAIL PROTECTED] > An: Mathieu Simon <[EMAIL PROTECTED]> > Betreff: Bug#492404: Acknowledgement (xserver-xorg-video-openchrome: > Resolutions only up to 800x600) > > Thank you for filing a new Bug report with Debian. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian X Strike Force > > If you wish to submit further information on this problem, please > send it to [EMAIL PROTECTED], as before. > > Please do not send mail to [EMAIL PROTECTED] unless you wish > to report a problem with the Bug-tracking system. > > > -- > 492404: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492404 > Debian Bug Tracking System > Contact [EMAIL PROTECTED] with problems -- kofi2k GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493894: /usr/lib/dri/i965_dri.so: undefined symbol: _glapi_tls_Context
thanks for the hints -- indeed with experimental xorg it loaded fine. unfortunately it made box unusable (doesn't redraw nicely... had to move window to get it redrawn fine) but the main part that it forbidden me to troubleshoot that crash bug -- with INTEL_DEBUG=buf I get completely stalled system. but that is not the issue of this bug report so I shut up ;-) On Tue, 05 Aug 2008, Julien Cristau wrote: > We build mesa with TLS support in experimental, which breaks the > interface between the dri driver and whatever loads it (libGL or the X > server). That means no AIGLX with xserver from sid and mesa from > experimental. Both from experimental should get AIGLX working. DRI > with libgl1-mesa-glx and libgl1-mesa-dri from experimental should work > with the sid xserver too, I think. -- Yaroslav Halchenko Research Assistant, Psychology Department, Rutgers-Newark Student Ph.D. @ CS Dept. NJIT Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171 101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102 WWW: http://www.linkedin.com/in/yarik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ubuntu-x] Using console-setup's keyboard setup for HAL and xorg input-hotplug
On Wed, Aug 6, 2008 at 16:20:22 +0100, Colin Watson wrote: > Should xinput be installed by default? No. BTW, it's a bit weird to show an example use of xinput set-pointer, seeing how the implementation of that in recent x servers boils down to returning BadDevice to the client. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474504: [qingy] changing to a virtual console kills X-session
On Wed, Aug 6, 2008 at 17:15:45 +0200, Brice Goglin wrote: > David Andel wrote: > > Hello Julien > > > > Ok, now I've got a Xorg log with an error which hopefully helps. > > > > David > > > > A debugging backtrace caught with gdb (from another machine) after > installing xserver-xorg-core-dbg would be better. If you need help, let > us know. > I don't think it's needed here, the log suggests it's a bug in the vbios or x86emu which triggers an assertion failure in the latter. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ubuntu-x] Using console-setup's keyboard setup for HAL and xorg input-hotplug
On Tue, Aug 05, 2008 at 07:08:25PM -0700, Bryce Harrington wrote: > Timo deployed the new input-hotplug config changes today. Please update > your intrepid, reboot, and try it out. > > I've also sketched in some rough docs about how to do configuration of > input devices with HAL and xinput (starting about halfway down): > > https://wiki.ubuntu.com/X/Config > > Please review for any errors or omissions. Less contrived examples > would also be appreciated. Should xinput be installed by default? Is it worth noting that it's generally a bug if the user needs to manually configure special keys with an FDI file just in order to get standard features to work (as opposed to user-specific customisations)? I think we should describe the standard keymap setup as well as the kind of specialised example you gave, and indicate how to change it so that both console and X are affected consistently. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474504: [qingy] changing to a virtual console kills X-session
David Andel wrote: > Hello Julien > > Ok, now I've got a Xorg log with an error which hopefully helps. > > David > A debugging backtrace caught with gdb (from another machine) after installing xserver-xorg-core-dbg would be better. If you need help, let us know. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
intel driver takes too much memory as VideoRam (128MB of 256 MB).
I have a compaq evo D510 USDT computer with 256 MB of RAM. This computer includes an Intel graphics chip that does not have its own VideoRam but uses part of the 256MB main RAM. lspci output includes 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) The BIOS appears to allocate 8 MB of RAM as VideoRam as dmesg output includes 247MB LOWMEM available. Linux agpgart interface v0.103 agpgart: Detected an Intel 830M Chipset. agpgart: Detected 8060K stolen memory. agpgart: AGP aperture is 128M @ 0xf000 However when the X-Server is started, it appears to use 128 MB as VideoRam. /var/log/Xorg.0.log contents include X.Org X Server 1.4.0.90 Build Operating System: Linux Debian (xorg-server 2:1.4.1~git20080517-2~lenny1) Current Operating System: Linux compaq 2.6.25-2-686 #1 SMP Fri Jul 18 17:46:56 UTC 2008 i686 (II) LoadModule: "intel" (II) Primary Device is: PCI 00:02:0 (--) Chipset 845G found (**) intel(0): Depth 24, (--) framebuffer bpp 32 (II) intel(0): Output VGA using initial mode 1152x864 (II) intel(0): detected 128 kB GTT. (II) intel(0): detected 8060 kB stolen memory. (II) intel(0): I830CheckAvailableMemory: 200700 kB available (==) intel(0): VideoRam: 131072 KB Whilst running X-Windows there is insufficient memory available to run programs, the computer continually swaps so runs very slowly. /proc/meminfo indicates the active memory is under 128 MB. How do I reduce the amount of memory taken as VideoRam by the intel driver ? (The intel man page includes the statement "The VideoRam option, which in the past had been necessary to allow more than some small amount of memory to be allocated, is now ignored"). Given that 1152x864x32 bpp = 4MB is used by the visual display and I'll want some VideoRam for holding display objects, what is a reasonable amount of RAM to use as VideoRam ? _ Your PC, mobile phone, and online services work together like never before. http://clk.atdmt.com/MRT/go/108587394/direct/01/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493963: xserver-xephyr: Allow starting Xephyr at other than 0,0 location
2008/8/6 Brice Goglin <[EMAIL PROTECTED]>: > Loic Grenie wrote: >> There is a ``-origin'' option of Xephyr that is used in PanoramiX >> mode but is ignored in non-PanoramiX mode. The following patch >> sets the upper-left corner of the Xephyr window to the coordinates >> specified as origin if PanoramiX is not activated. > Could you open an upstream bug on bugzilla.freedesktop.org so that the > upstream dev have a chance to look at your patch? I've a problem with upstream Xephyr: it does not compile on my machine. I've tracked the problem to a difference in the size of an integer (I think it is XID which is 32 bit in the library and 64 bit inside the server which is causing a conflict because Xephyr is both a client and a server). I can obviously open a bug and file a patch, but I cannot test it. > Before doing so, you might want to check that Xephyr from experimental > has the same problem Upstream git has misses that same feature (it is not so much a problem as a missing feature). I've not tested Xephyr from experimental, but I don't see how it could have that feature since it is neither present in freedesktop's Xephyr nor in Lenny's one. > and that your patch still applies on top of upstream git master. My patch as is does not apply (because a function changed interface in between) but it is trivial to adapt. I'll try to submit to Freedesktop. Thanks, Loïc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
On Wed, Aug 6, 2008 at 12:53 PM, Brice Goglin <[EMAIL PROTECTED]> wrote: [...] > > Did you check that Xorg was actually stuck in there ? Well, not completely stuck but as reported earlier, 100% CPU usage by X process, mouse pointer responding to movements but not buttons press, keyboard not responding. > You should interrupt the process and get the backtrace, then hit 'c' to > make the process continue, interrupt again, ... several times and > compare the backtraces. I've done that (well... two times instead of several) but only included one backtrace as they were identical. I will try to grab more next time and check for differences. On Wed, Aug 6, 2008 at 1:07 PM, Michel Dänzer <[EMAIL PROTECTED]> wrote: [...] > It's a classic backtrace for a GPU lockup - allocating indirect buffers > is one point where things can get stuck if the GPU isn't making > progress. Does it exclude an hardware glitch? As I wrote above, it seems to happen in the first few minutes after boot, never happened after few hours of use. It wouldn't surprise me as the video card is a pretty old Radeon 9000 (RV250), four or five years, if not more. -- Andrea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476282: Even a fresh install exhibits this behaviour
I've just been looking through my /var/log/aptitude(.?.gz) files and it looks to me that I first installed compiz at this version (compiz 0.6.3~git20080115.0ea58487-1) and upgraded to 0.7.6-3 then to -5, so I've not at any point upgraded from an earlier version, and I still had what I would consider a buggy experience of not having the decoration module enabled by default. This machine's only recently been installed from scratch (around the middle of june) so it really doesn't look to me like the issue has to do with pre-existing settings. Perhaps installing 0.7.x on a clean system would not exhibit have the no-decorations problem (I've not tested that case), but at the least it would seem a good idea to have some kind of warning triggered when starting compiz. Something along the lines of the following might work: You don't have the decoration module enabled, this may leave you with an unusable desktop with no window borders etc. To view/set the list of enabled modules, use gconftool --get /apps/compiz/general/allscreens/options/active_plugins and gconftool --set /apps/compiz/general/allscreens/options/active_plugins '[list,of,modules,to,enable]' or a graphical tool such as ccsm Does that sound fair? Certainly, I would expect the default to include the decoration module in the case that there are no pre-existing settings specifically excluding it. HTH Sam "SammyTheSnake" Penny __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
On Wed, 2008-08-06 at 12:53 +0200, Brice Goglin wrote: > Andrea Vettorello wrote: > >> The last two days, without GDB, again it worked with no issues, so the > >> glitch, hardware or software, seems disappeared. > >> > > > > I spoken too early. Well, this time I was able to get a backtrace, > > don't know if useful: > > > > Program received signal SIGINT, Interrupt. > > 0xb7f0b424 in __kernel_vsyscall () > > #0 0xb7f0b424 in __kernel_vsyscall () > > #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 > > #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 > > #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) > > at ../../src/radeon_accel.c:611 > > #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) > > at ../../src/radeon_accel.c:665 > > #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) > > at ../../src/radeon_accelfuncs.c:686 > > #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, > > w=912, h=173, src=0xa5ded320 "", srcwidth=3648, rop=3, > > planemask=4294967295, trans=-1, bpp=32, depth=24) > > at ../../../../hw/xfree86/xaa/xaaImage.c:370 > > #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, > > pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) > > at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 > > #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, > > pDstDrawable=0xa10f230, > > pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, > > doBitBlt=0xb7882330 , bitPlane=0) > > at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 > > #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, > > pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, > > height=785, dstx=7, dsty=3) at > > ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 > > #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, > > pGC=0xa10c2a0, > > srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) > > at ../../../miext/cw/cw_ops.c:201 > > #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, > > pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) > > at ../../../miext/damage/damage.c:834 > > #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at > > ../../dix/dispatch.c:1802 > > #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) > > at ../../Xext/xace.c:281 > > #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 > > #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= > > Cannot access memory at address 0xc0286431 > > ) at ../../dix/main.c:452 > > > > Did you check that Xorg was actually stuck in there ? It's a classic backtrace for a GPU lockup - allocating indirect buffers is one point where things can get stuck if the GPU isn't making progress. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xorg-server: Changes to 'ubuntu'
debian/patches/130_fedora_fix_procxkbsetxyz_to_work_on_all.patch | 2245
++
debian/patches/136_fedora_force_switchcorekeyboard_for_evdev.patch | 69
2 files changed, 2314 insertions(+)
New commits:
commit 02def36766818699103799a478a44a3d0e17eac0
Author: Timo Aaltonen <[EMAIL PROTECTED]>
Date: Wed Aug 6 13:56:10 2008 +0300
actually add the patches.
diff --git a/debian/patches/130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
b/debian/patches/130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
new file mode 100644
index 000..13e197a
--- /dev/null
+++ b/debian/patches/130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
@@ -0,0 +1,2245 @@
+From 6d1201b05ed61aec508d5d9f88e3a2d33be39849 Mon Sep 17 00:00:00 2001
+From: Peter Hutterer <[EMAIL PROTECTED]>
+Date: Thu, 31 Jul 2008 16:03:21 +0930
+Subject: [PATCH] xkb: fix up ProcXkbSetXYZ to work on all core devices.
+
+Simple principle: if the client requests an xkb change on the core keyboard,
+apply the same change to all core-sending keyboard devices. This way, if you
+change the layout on the VCK, you get the same layout on all devices.
+
+That's the theory anyway, the implementation makes you want to gauge your eyes
+out.
+---
+ xkb/xkb.c | 1880 +++--
+ 1 files changed, 1210 insertions(+), 670 deletions(-)
+
+diff --git a/xkb/xkb.c b/xkb/xkb.c
+index 07f57a7..cc2f77c 100644
+--- a/xkb/xkb.c
b/xkb/xkb.c
+@@ -24,6 +24,31 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
+
+ /
+
++/* Copyright © 2008 Red Hat, Inc.
++
++Permission is hereby granted, free of charge, to any person obtaining a
++copy of this software and associated documentation files (the "Software"),
++to deal in the Software without restriction, including without limitation
++the rights to use, copy, modify, merge, publish, distribute, sublicense,
++and/or sell copies of the Software, and to permit persons to whom the
++Software is furnished to do so, subject to the following conditions:
++
++The above copyright notice and this permission notice (including the next
++paragraph) shall be included in all copies or substantial portions of the
++Software.
++
++THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
++IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
++FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
++THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
++LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
++FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
++DEALINGS IN THE SOFTWARE.
++
++Authors: Peter Hutterer
++
++*/
++
+ #ifdef HAVE_DIX_CONFIG_H
+ #include
+ #endif
+@@ -348,17 +373,119 @@ ProcXkbSelectEvents(ClientPtr client)
+ }
+
+ /******/
++/**
++ * Ring a bell on the given device for the given client.
++ */
++static int
++_XkbBell(ClientPtr client, DeviceIntPtr dev, WindowPtr pWin,
++ int bellClass, int bellID, int pitch, int duration,
++ int percent, int forceSound, int eventOnly, Atom name)
++{
++int base;
++pointer ctrl;
++int oldPitch, oldDuration;
++int newPercent;
++
++if (bellClass == KbdFeedbackClass) {
++KbdFeedbackPtrk;
++if (bellID==XkbDfltXIId)
++k= dev->kbdfeed;
++else {
++for (k=dev->kbdfeed; k; k=k->next) {
++if (k->ctrl.id == bellID)
++break;
++}
++}
++if (!k) {
++client->errorValue = _XkbErrCode2(0x5,bellID);
++return BadValue;
++}
++base = k->ctrl.bell;
++ctrl = (pointer) &(k->ctrl);
++oldPitch= k->ctrl.bell_pitch;
++oldDuration= k->ctrl.bell_duration;
++if (pitch!=0) {
++if (pitch==-1)
++k->ctrl.bell_pitch= defaultKeyboardControl.bell_pitch;
++else k->ctrl.bell_pitch= pitch;
++}
++if (duration!=0) {
++if (duration==-1)
++k->ctrl.bell_duration= defaultKeyboardControl.bell_duration;
++else k->ctrl.bell_duration= duration;
++}
++}
++else if (bellClass == BellFeedbackClass) {
++BellFeedbackPtr b;
++if (bellID==XkbDfltXIId)
++b= dev->bell;
++else {
++for (b=dev->bell; b; b=b->next) {
++if (b->ctrl.id == bellID)
++break;
++}
++}
++if (!b) {
++client->errorValue = _XkbErrCode2(0x6,bellID);
++return BadValue;
++}
++base = b->ctrl.percent;
++ctrl = (pointer) &(b->ctrl);
++oldPitch= b->ctrl.pitch;
++oldDuration= b->ctrl.duration;
++if (pitch!=0) {
++if (pitch==-1)
++
xorg-server: Changes to 'ubuntu'
debian/changelog|9 ++
debian/patches/130_fedora_call_switchcorekeyboard.patch | 61
debian/patches/series |3
3 files changed, 11 insertions(+), 62 deletions(-)
New commits:
commit 9a97ecdb6fbb50c7b0699f8faa584c059ec463ee
Author: Timo Aaltonen <[EMAIL PROTECTED]>
Date: Wed Aug 6 13:45:18 2008 +0300
Add a couple of patches from Fedora to allow clients to change the layout.
added;
130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
136_fedora_force_switchcorekeyboard_for_evdev.patch
dropped;
130_fedora_call_switchcorekeyboard.patch
diff --git a/debian/changelog b/debian/changelog
index 8a7f15b..21011b4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+xorg-server (2:1.4.99.906-1ubuntu3) intrepid; urgency=low
+
+ * 130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
+136_fedora_force_switchcorekeyboard_for_evdev.patch
+- Allow clients to set the layout.
+ * Drop 130_fedora_call_switchcorekeyboard.patch, obsoleted.
+
+ -- Timo Aaltonen <[EMAIL PROTECTED]> Wed, 06 Aug 2008 13:30:28 +0300
+
xorg-server (2:1.4.99.906-1ubuntu2) intrepid; urgency=low
* Add 135_rethrow_signals.patch
diff --git a/debian/patches/130_fedora_call_switchcorekeyboard.patch
b/debian/patches/130_fedora_call_switchcorekeyboard.patch
deleted file mode 100644
index 304d79e..000
--- a/debian/patches/130_fedora_call_switchcorekeyboard.patch
+++ /dev/null
@@ -1,61 +0,0 @@
-From b2943b507261d1c68a6266b090ec44495d7796a1 Mon Sep 17 00:00:00 2001
-From: Peter Hutterer <[EMAIL PROTECTED]>
-Date: Mon, 28 Jul 2008 12:17:17 +0930
-Subject: [PATCH] xfree86: call SwitchCoreKeyboard for first physical device.
-
-The VCK's keymap is different to the (evdev) keyboard's keymap. Any changes to
-the VCK are lost when the first key is pressed (see X.Org Bug 16364). By
-calling SwitchCoreKeyboard for the first hotplugged keyboard, the keymap is
-toggled already when the first apps start.
-
-This fixes GNOME, which stores the keycode instead of the keysym.
-Fixes xmodmap, etc. settings in xinitrc or otherwise set before the first key
-press.
-
-This breaks if the first hotplugged keyboard is not the actual keyboard the
-user wants to use.
- hw/xfree86/common/xf86Xinput.c | 27 +++
- 1 files changed, 27 insertions(+), 0 deletions(-)
-
-diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
-index 710e787..fe08626 100644
a/hw/xfree86/common/xf86Xinput.c
-+++ b/hw/xfree86/common/xf86Xinput.c
-@@ -423,6 +423,33 @@ NewInputDeviceRequest (InputOption *options, DeviceIntPtr
*pdev)
- (!is_auto || xf86Info.autoEnableDevices))
- EnableDevice(dev);
-
-+/* XXX: The VCK always starts with built-in defaults for keymap. These
-+ * defaults are different to the evdev ones. When the first key is hit on
-+ * an extension device, the keymap is copied into the VCK's and any
-+ * changes made at runtime to the VCK map are lost.
-+ *
-+ * If this is the first real keyboard to activate, force a
-+ * SwitchCoreKeyboard so the VCK has the same keymap as we do.
-+ *
-+ * Next time we hit a key, we don't change the map over anymore (see
-+ * SwitchCoreKeyboard), and live happily ever after.
-+ * Until we have 2 physical keyboards. Or the first real keyboard isn't
-+ * actually the one we use. Oh well.
-+ */
-+if (dev->key)
-+{
-+DeviceIntPtr it;
-+
-+for (it = inputInfo.keyboard->next; it; it = it->next)
-+{
-+if (it->key && it != dev)
-+break;
-+}
-+
-+if (!it) /* no other keyboard found */
-+SwitchCoreKeyboard(dev);
-+}
-+
- *pdev = dev;
- return Success;
-
---
-1.5.5.1
-
diff --git a/debian/patches/series b/debian/patches/series
index 16fc637..7cbcc6e 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,9 +9,10 @@
110_fedora_no_move_damage.patch
121_only_switch_vt_when_active.diff
123_no_composite_for_xvfb_run.patch
-130_fedora_call_switchcorekeyboard.patch
+130_fedora_fix_procxkbsetxyz_to_work_on_all.patch
131_remove_open-coded_strcasestr.patch
132_add_parsing_for_xkb.options.patch
133_support_strlist_for_xkboptions.patch
134_protect_against_out_of_bounds.patch
135_rethrow_signals.patch
+136_fedora_force_switchcorekeyboard_for_evdev.patch
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
Andrea Vettorello wrote: >> The last two days, without GDB, again it worked with no issues, so the >> glitch, hardware or software, seems disappeared. >> > > I spoken too early. Well, this time I was able to get a backtrace, > don't know if useful: > > Program received signal SIGINT, Interrupt. > 0xb7f0b424 in __kernel_vsyscall () > #0 0xb7f0b424 in __kernel_vsyscall () > #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 > #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 > #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) > at ../../src/radeon_accel.c:611 > #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) > at ../../src/radeon_accel.c:665 > #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) > at ../../src/radeon_accelfuncs.c:686 > #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, > w=912, h=173, src=0xa5ded320 "", srcwidth=3648, rop=3, > planemask=4294967295, trans=-1, bpp=32, depth=24) > at ../../../../hw/xfree86/xaa/xaaImage.c:370 > #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, > pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) > at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 > #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, > pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, > doBitBlt=0xb7882330 , bitPlane=0) > at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 > #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, > pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, > height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 > #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, > srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) > at ../../../miext/cw/cw_ops.c:201 > #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, > pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) > at ../../../miext/damage/damage.c:834 > #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802 > #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) > at ../../Xext/xace.c:281 > #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 > #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= > Cannot access memory at address 0xc0286431 > ) at ../../dix/main.c:452 > Did you check that Xorg was actually stuck in there ? You should interrupt the process and get the backtrace, then hit 'c' to make the process continue, interrupt again, ... several times and compare the backtraces. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493963: xserver-xephyr: Allow starting Xephyr at other than 0,0 location
Loic Grenie wrote: > There is a ``-origin'' option of Xephyr that is used in PanoramiX > mode but is ignored in non-PanoramiX mode. The following patch > sets the upper-left corner of the Xephyr window to the coordinates > specified as origin if PanoramiX is not activated. > Could you open an upstream bug on bugzilla.freedesktop.org so that the upstream dev have a chance to look at your patch? Before doing so, you might want to check that Xephyr from experimental has the same problem and that your patch still applies on top of upstream git master. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
On Tue, Aug 5, 2008 at 20:02:54 +0200, Thomas Zander wrote: > On Tuesday 5. August 2008 19:49:01 Julien Cristau wrote: > > On Tue, Aug 5, 2008 at 19:13:10 +0200, Thomas Zander wrote: > > > To reproduce type; > > > fc-match -v helvetica | grep antialias > > > If you get 'FcTrue(w)' then you see the problem as a bitmap font can > > > never be antialiased. > > > > And if I don't? Please be more specific. > > > > "fc-match -s -v helvetica |grep file" doesn't seem to list anything > > from xfonts-100dpi here. What file are you talking about? > > not "grep file", thats not what I wrote. > Yes, but what you wrote doesn't tell me anything, so I tried to look further because I don't understand your report. It sounded like fc-match -v helvetica matched some file from xfonts-100dpi, but you didn't say which, so I tried to look, and it doesn't here. > 1) make sure you have the package installed. duh. it is. > 2) run > fc-match -v helvetica | grep antialias > 3) check output. > empty. > Your output should either be; > antialias: FcTrue(w) > or it is different. > If it is the FcTrue one, then fontconfig is reporting the bitmap font to be > antialiased. Something that is impossible for a bitmap font so > the font is announced to fontconfig incorrectly. > > Just FYI; here is the full output of fc-match (without the limiting grep) > > $fc-match -v Helvetica > Pattern has 27 elts (size 32) > family: "Helvetica"(s) > style: "Regular"(s) > slant: 0(i)(s) > weight: 80(i)(s) > width: 100(i)(s) > size: 12(f)(s) > pixelsize: 11(f)(s) > foundry: "Adobe"(s) > antialias: FcTrue(w) > hintstyle: 1(i)(w) > hinting: FcTrue(w) > verticallayout: FcFalse(s) > autohint: FcFalse(s) > globaladvance: FcTrue(s) > file: "/usr/share/fonts/X11/100dpi/helvR08.pcf.gz"(s) > index: 0(i)(s) > outline: FcFalse(s) > scalable: FcFalse(s) > dpi: 75(f)(s) > rgba: 1(i)(w) > scale: 1(f)(s) > charset: : 0001 7fff > > 0001: 7fff a4844240 1861c183 e00d > ff313fff > 0002: cfff 000fffc0 8311 02200020 40007380 3800 3f00efc0 > 4000 > 0003: 4000 00b0 1000 > > 001e: 03ff f3f3fcf3 3fcf3cf3 > 033fcf3f > 0020: ff3f0fff 06010047 0010 000e 3260 > > 0021: 0208 00040c04 > > 0022: 02240019 0040 0600 0003c037 > > (s) > lang: > aa|af|ast|ay|bi|br|bs|ca|ch|co|cs|cy|da|de|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|ga|gd|gl|gn|gv|haw|ho|hr|hu|ia|ibo|id|ie|io|is|it|ki| > kl|kw|la|lb|lt|lv|mg|mh|mi|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|pl|pt|rm|ro|se|sk|sl|sm|sma|smj|smn|so|sq|ss|st|sv|sw|tn|to|tr|ts|ven| > vo|vot|wa|wen|wo|xh|yap|zu(s) > fontversion: 0(i)(s) > fontformat: "PCF"(s) > embeddedbitmap: FcTrue(s) > decorative: FcFalse(s) > Not seeing this at all here. Might be dependant on fontconfig configuration, but you didn't give any info about that, so... Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
Thomas Zander wrote: > Judging by this line you pasted; > >> file: "/usr/share/fonts/X11/75dpi/helvR12.pcf.gz"(s) >> > > you also have the 75 dpi fonts package installed (xfonts-75dpi) and > fontconfig > returns that result before the one this report is about. > Please deinstall the 75dpi package and run the line again; > Still the same: $ fc-match -v Helvetica Pattern has 26 elts (size 32) family: "Helvetica"(s) style: "Regular"(s) slant: 0(i)(s) weight: 80(i)(s) width: 100(i)(s) size: 12(f)(s) pixelsize: 11(f)(s) foundry: "Adobe"(s) antialias: FcFalse(s) hintstyle: 3(i)(s) hinting: FcTrue(s) verticallayout: FcFalse(s) autohint: FcFalse(s) globaladvance: FcTrue(s) file: "/usr/share/fonts/X11/100dpi/helvR08.pcf.gz"(s) Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
xorg-server: Changes to 'ubuntu'
debian/changelog | 10 ++
debian/patches/135_rethrow_signals.patch | 19 +++
debian/patches/series|1 +
3 files changed, 30 insertions(+)
New commits:
commit 1f230c7ce2ecd93d27a1401cb03ec9e709d68977
Author: Bryce Harrington <[EMAIL PROTECTED]>
Date: Wed Aug 6 13:26:16 2008 +0300
Add 135_rethrow_signals.patch
Currently Xorg "eats" its crash signals, issuing an error message
that it caught the signal and then aborts. This patch raises the
signal it caught, so that subsequent crash handlers (i.e. apport)
can also catch and act on it.
diff --git a/debian/changelog b/debian/changelog
index 72b616a..8a7f15b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+xorg-server (2:1.4.99.906-1ubuntu2) intrepid; urgency=low
+
+ * Add 135_rethrow_signals.patch
+- Currently Xorg "eats" its crash signals, issuing an error message
+ that it caught the signal and then aborts. This patch raises the
+ signal it caught, so that subsequent crash handlers (i.e. apport)
+ can also catch and act on it.
+
+ -- Bryce Harrington <[EMAIL PROTECTED]> Tue, 05 Aug 2008 16:20:46 -0700
+
xorg-server (2:1.4.99.906-1ubuntu1) intrepid; urgency=low
* Merge with debian experimental, 1.5RC6 (LP: #247120, #253021)
diff --git a/debian/patches/135_rethrow_signals.patch
b/debian/patches/135_rethrow_signals.patch
new file mode 100644
index 000..6d3faf1
--- /dev/null
+++ b/debian/patches/135_rethrow_signals.patch
@@ -0,0 +1,19 @@
+diff -Nurp xorg-server-1.4.99.905/hw/xfree86/common/xf86Events.c
xorg-server-1.4.99.905-working/hw/xfree86/common/xf86Events.c
+--- xorg-server-1.4.99.905/hw/xfree86/common/xf86Events.c 2008-06-30
13:11:03.0 -0700
xorg-server-1.4.99.905-working/hw/xfree86/common/xf86Events.c
2008-07-14 08:23:51.0 -0700
+@@ -763,6 +763,15 @@ xf86SigHandler(int signo)
+
+ xorg_backtrace();
+
++ switch (signo) {
++ case SIGSEGV:
++ case SIGBUS:
++ case SIGILL:
++ case SIGFPE:
++ ErrorF ("Caught signal %d. Server aborting\n", signo);
++ raise (signo);
++ }
++
+ FatalError("Caught signal %d. Server aborting\n", signo);
+ }
+
diff --git a/debian/patches/series b/debian/patches/series
index 41fac00..16fc637 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -14,3 +14,4 @@
132_add_parsing_for_xkb.options.patch
133_support_strlist_for_xkboptions.patch
134_protect_against_out_of_bounds.patch
+135_rethrow_signals.patch
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
On Wed, 2008-08-06 at 10:53 +0200, Thomas Zander wrote: > On Wednesday 6. August 2008 10:17:44 Brice Goglin wrote: > > tags 493880 moreinfo unreproducible > > thank you > > > > On Tue, Aug 05, 2008 at 08:02:54PM +0200, Thomas Zander wrote: > > > 1) make sure you have the package installed. > > > > $ dpkg -s xfonts-100dpi > > Package: xfonts-100dpi > > Status: install ok installed > > [...] > > Version: 1:1.0.0-4 > > Judging by this line you pasted; > > file: "/usr/share/fonts/X11/75dpi/helvR12.pcf.gz"(s) > > you also have the 75 dpi fonts package installed (xfonts-75dpi) and > fontconfig > returns that result before the one this report is about. > Please deinstall the 75dpi package and run the line again; [EMAIL PROTECTED]|12:14:28> fc-match -v helvetica | grep -e antialias -e file antialias: FcTrue(w) file: "/usr/share/fonts/X11/75dpi/helvR12.pcf.gz"(s) I suspect this is due to fontconfig (configuration) rather than due to the fonts themselves... -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#490071: xorg occupies all cpu time
> The last two days, without GDB, again it worked with no issues, so the > glitch, hardware or software, seems disappeared. I spoken too early. Well, this time I was able to get a backtrace, don't know if useful: Program received signal SIGINT, Interrupt. 0xb7f0b424 in __kernel_vsyscall () #0 0xb7f0b424 in __kernel_vsyscall () #1 0xb7d77ed9 in ioctl () from /lib/i686/cmov/libc.so.6 #2 0xb7aff23d in drmDMA () from /usr/lib/libdrm.so.2 #3 0xb7a87f79 in RADEONCPGetBuffer (pScrn=0x9dcd8a0) at ../../src/radeon_accel.c:611 #4 0xb7a88113 in RADEONCPFlushIndirect (pScrn=0x9dcd8a0, discard=1) at ../../src/radeon_accel.c:665 #5 0xb7a929e3 in RADEONCPScanlinePacket (pScrn=0x9dcd8a0, bufno=0) at ../../src/radeon_accelfuncs.c:686 #6 0xb7890878 in XAAWritePixmapScanline (pScrn=0x9dcd8a0, x=343, y=146, w=912, h=173, src=0xa5ded320 "", srcwidth=3648, rop=3, planemask=4294967295, trans=-1, bpp=32, depth=24) at ../../../../hw/xfree86/xaa/xaaImage.c:370 #7 0xb7882448 in XAADoImageWrite (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, prgnDst=0xbfe26150, pptSrc=0xbfe260f0) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:218 #8 0xb7881bf2 in XAABitBlt (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3, doBitBlt=0xb7882330 , bitPlane=0) at ../../../../hw/xfree86/xaa/xaaBitBlt.c:203 #9 0xb7882a3f in XAACopyArea (pSrcDrawable=0xa5bcd008, pDstDrawable=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../../hw/xfree86/xaa/xaaCpyArea.c:66 #10 0xb78c449a in cwCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, w=912, h=785, dstx=7, dsty=3) at ../../../miext/cw/cw_ops.c:201 #11 0x08177a26 in damageCopyArea (pSrc=0xa5bcd008, pDst=0xa10f230, pGC=0xa10c2a0, srcx=0, srcy=0, width=912, height=785, dstx=7, dsty=3) at ../../../miext/damage/damage.c:834 #12 0x0808be86 in ProcCopyArea (client=0xa07bec0) at ../../dix/dispatch.c:1802 #13 0x08155004 in XaceCatchDispatchProc (client=0xa07bec0) at ../../Xext/xace.c:281 #14 0x0808de64 in Dispatch () at ../../dix/dispatch.c:502 #15 0x08074795 in main (argc=9, argv=0xbfe26844, envp= Cannot access memory at address 0xc0286431 ) at ../../dix/main.c:452 The program is running. Quit anyway (and detach it)? (y or n) Detaching from program: /usr/bin/Xorg, process 2890 -- Andrea -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493963: xserver-xephyr: Allow starting Xephyr at other than 0,0 location
Package: xserver-xephyr
Version: 2:1.4.2-2
Severity: wishlist
Tags: patch
Background:
I'd like to use Xephyr to have a multiseat setup. My graphic card has
two displays and I don't know how to do differently than having one
large screen encompassing both monitors (ideally I'd have :0.0 on
first monitor and :0.1 on the second, but hey, I'm not capable). I
start Xephyr to have two X servers.
Problem:
I'd like to start one Xephyr on first monitor and one Xephyr on
second monitor. Without window manager it's a bit tricky.
Workaround:
I can use an X client that honor the -geometry option and use
the ``-parent'' option of Xephyr. It's realy ugly (but it works).
Better approach:
There is a ``-origin'' option of Xephyr that is used in PanoramiX
mode but is ignored in non-PanoramiX mode. The following patch
sets the upper-left corner of the Xephyr window to the coordinates
specified as origin if PanoramiX is not activated.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25.13 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages xserver-xephyr depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.1-2simple interprocess messaging syst
ii libfontenc1 1:1.0.4-3 X11 font encoding library
ii libhal1 0.5.11-2 Hardware Abstraction Layer - share
ii libpixman-1-0 0.10.0-2 pixel-manipulation library for X a
ii libx11-6 2:1.1.4-2 X11 client-side library
ii libxau6 1:1.0.3-3 X11 authorisation library
ii libxdmcp6 1:1.0.2-3 X11 Display Manager Control Protoc
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
ii libxfont1 1:1.3.3-1 X11 font rasterisation library
ii x11-common1:7.3+14 X Window System (X.Org) infrastruc
Versions of packages xserver-xephyr recommends:
ii xbase-clients 1:7.3+14 miscellaneous X clients - metapack
ii xfonts-base 1:1.0.0-5 standard fonts for X
xserver-xephyr suggests no packages.
-- no debconf information
diff -u hw/kdrive/ephyr.orig/ephyr.c hw/kdrive/ephyr/ephyr.c
--- hw/kdrive/ephyr.orig/ephyr.c 2008-05-12 18:53:59.0 +0200
+++ hw/kdrive/ephyr/ephyr.c 2008-08-05 12:31:50.0 +0200
@@ -227,7 +227,7 @@
else
buffer_height = 3 * screen->height;
- priv->base = hostx_screen_init (screen->width, screen->height, buffer_height);
+ priv->base = hostx_screen_init (screen->origin.x, screen->origin.y, screen->width, screen->height, buffer_height);
screen->memory_base = (CARD8 *) (priv->base);
screen->memory_size = priv->bytes_per_line * buffer_height;
diff -u hw/kdrive/ephyr.orig/hostx.c hw/kdrive/ephyr/hostx.c
--- hw/kdrive/ephyr.orig/hostx.c 2008-05-12 18:53:59.0 +0200
+++ hw/kdrive/ephyr/hostx.c 2008-08-05 22:23:35.0 +0200
@@ -445,7 +445,7 @@
* by fakexa for storing offscreen pixmap data.
*/
void*
-hostx_screen_init (int width, int height, int buffer_height)
+hostx_screen_init (int x, int y, int width, int height, int buffer_height)
{
int bitmap_pad;
Boolshm_success = False;
@@ -533,6 +533,9 @@
XSetWMNormalHints(HostX.dpy, HostX.win, size_hints);
XFree(size_hints);
+#ifndef PANORAMIX
+ XMoveWindow(HostX.dpy, HostX.win, x, y);
+#endif
XMapWindow(HostX.dpy, HostX.win);
XSync(HostX.dpy, False);
diff -u hw/kdrive/ephyr.orig/hostx.h hw/kdrive/ephyr/hostx.h
--- hw/kdrive/ephyr.orig/hostx.h 2008-05-12 18:53:59.0 +0200
+++ hw/kdrive/ephyr/hostx.h 2008-08-05 12:26:56.0 +0200
@@ -147,7 +147,7 @@
unsigned char b);
void*
-hostx_screen_init (int width, int height, int buffer_height);
+hostx_screen_init (int x, int y, int width, int height, int buffer_height);
void
hostx_paint_rect(int sx,int sy,
Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
On Wednesday 6. August 2008 10:17:44 Brice Goglin wrote: > tags 493880 moreinfo unreproducible > thank you > > On Tue, Aug 05, 2008 at 08:02:54PM +0200, Thomas Zander wrote: > > 1) make sure you have the package installed. > > $ dpkg -s xfonts-100dpi > Package: xfonts-100dpi > Status: install ok installed > [...] > Version: 1:1.0.0-4 Judging by this line you pasted; > file: "/usr/share/fonts/X11/75dpi/helvR12.pcf.gz"(s) you also have the 75 dpi fonts package installed (xfonts-75dpi) and fontconfig returns that result before the one this report is about. Please deinstall the 75dpi package and run the line again; > > 2) run > > fc-match -v helvetica | grep antialias Thanks. ps. this report is based on a clean installed lenny. Just installed it from a netinstall a few days ago. And I didn't change any relevant config files. -- Thomas Zander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#474504: [qingy] changing to a virtual console kills X-session
Hello Julien Ok, now I've got a Xorg log with an error which hopefully helps. David X.Org X Server 1.4.2 Release Date: 11 June 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux Debian (xorg-server 2:1.4.2-3) Current Operating System: Linux apollo 2.6.26-1-686 #1 SMP Wed Jul 30 20:02:15 UTC 2008 i686 Build Date: 02 August 2008 11:27:26PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.1.log", Time: Wed Aug 6 10:11:08 2008 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "Plug & Play" (**) | |-->Device "Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter" (**) |-->Input Device "Generic Keyboard" (**) |-->Input Device "Configured Mouse" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) No APM support in BIOS or kernel (II) Loader magic: 0x81e3ca0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 2.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (II) LoadModule: "pcidata" (II) Loading /usr/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor="X.Org Foundation" compiled for 1.4.2, module version = 1.0.0 ABI class: X.Org Video Driver, version 2.0 (++) using VT number 1 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1039,0661 card 1043,8113 rev 11 class 06,00,00 hdr 80 (II) PCI: 00:01:0: chip 1039,0003 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:02:0: chip 1039,0964 card , rev 36 class 06,01,00 hdr 80 (II) PCI: 00:02:5: chip 1039,5513 card 1043,810e rev 01 class 01,01,80 hdr 00 (II) PCI: 00:02:7: chip 1039,7012 card 1043,810f rev a0 class 04,01,00 hdr 00 (II) PCI: 00:03:0: chip 1039,7001 card 1043,810e rev 0f class 0c,03,10 hdr 80 (II) PCI: 00:03:1: chip 1039,7001 card 1043,810e rev 0f class 0c,03,10 hdr 00 (II) PCI: 00:03:2: chip 1039,7001 card 1043,810e rev 0f class 0c,03,10 hdr 00 (II) PCI: 00:03:3: chip 1039,7002 card 1043,810e rev 00 class 0c,03,20 hdr 00 (II) PCI: 00:09:0: chip 11c1,5811 card 11c1,5811 rev 04 class 0c,00,10 hdr 00 (II) PCI: 00:0a:0: chip 109e,036e card 0070,13eb rev 02 class 04,00,00 hdr 80 (II) PCI: 00:0a:1: chip 109e,0878 card 0070,13eb rev 02 class 04,80,00 hdr 80 (II) PCI: 00:0b:0: chip 10ec,8139 card 1043,8109 rev 10 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 1039,6330 card 1043,8113 rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x000a (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xdfe0 - 0xdfef (0x10) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xcfd0 - 0xdfcf (0x1000) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:2:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--) PCI: (0:10:0) Brooktree Corporation Bt878 Video Capture rev 2, Mem @ 0xdfdfe000/12 (--) PCI:*(1:0:0) Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter rev 0, Mem @ 0xd000/27, 0xdfee/17, I/O @ 0xdc00/7 (II) Addressable bus resource ranges are [0] -1 0 0x - 0x (0x0) MX[B] [1] -1 0 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x00ff (0x100) IX[B] (II) PCI Memory resource overlap reduced 0xe000 from 0xe3ff to 0xdfff (II) Active PCI resource ranges: [0] -1 0 0xdfffa800 - 0x
Bug#493134: xserver-xorg-video-ati: no resolution higher than 640x480 possible
> > Please try again with the driver from git. I fixed up several RS4xx > issues today. > I used the version from sid (accoding to git, it already contains the changes) and everything works fine now. Without the panelsize option, the x-contents were shown in the top-left corner of the screen and with the panelsize option, everything works as expected. Thanks a lot for your help, Eike PS: If this is/was a more general problem and you need something to be tested, please let me know. Otherwise, feel free to close this report. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 493921 is wishlist, severity of 493290 is wishlist
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.34 > severity 493921 wishlist Bug#493921: lintian: file-in-unusual-dir redundant in /opt due to dir-or-file-in-opt Severity set to `wishlist' from `normal' > severity 493290 wishlist Bug#493290: xserver-xorg-video-intel: Screen randomly flickers when using VGA output Severity set to `wishlist' from `important' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493290: severity of 493290 is important, severity of 493920 is wishlist
# Automatically generated email from bts, devscripts version 2.10.34 # Sorry, typoed the bug number severity 493290 important severity 493920 wishlist -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 493290 is important, severity of 493920 is wishlist
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.34 > # Sorry, typoed the bug number > severity 493290 important Bug#493290: xserver-xorg-video-intel: Screen randomly flickers when using VGA output Severity set to `important' from `wishlist' > severity 493920 wishlist Bug#493920: lintian: debconf-error-requires-versioned-depends test apparently obsolete Severity set to `wishlist' from `normal' > End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493901: xserver-xorg-core: X fails to start in a Xen DomU (using Xen Framebuffer)
Quoting Julien Cristau <[EMAIL PROTECTED]>: This is supposed to be addressed by patch 47_fbdevhw_magic_numbers.diff. I didn't see this patch (which was disabled in 1.3.99.0-1). I re-enabled it and then recompiled xorg-server and it solves correctly this problem. Thanks, Olivier; -- gpg --keyserver pgp.mit.edu --recv-keys 0x43CEA851 __ Olivier Tétard - toutoune25 site : http://toutoune25.miskin.fr/ Jabber : [EMAIL PROTECTED] __ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
Processing commands for [EMAIL PROTECTED]: > tags 493880 moreinfo unreproducible Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased There were no tags set. Tags added: moreinfo, unreproducible > thank you Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493880: xfonts-100dpi: Helvetica from this package is reported by fc-match to beantialiased
tags 493880 moreinfo unreproducible thank you On Tue, Aug 05, 2008 at 08:02:54PM +0200, Thomas Zander wrote: > 1) make sure you have the package installed. $ dpkg -s xfonts-100dpi Package: xfonts-100dpi Status: install ok installed [...] Version: 1:1.0.0-4 > 2) run > fc-match -v helvetica | grep antialias [EMAIL PROTECTED]:~$ fc-match -v helvetica | grep antialias antialias: FcFalse(s) I never touched anything in this package since I have no clue about fonts. Since both Julien and I don't see anything like this, you probably have something screwed in your setup. Brice PS: $ fc-match -v Helvetica Pattern has 26 elts (size 32) family: "Helvetica"(s) style: "Regular"(s) slant: 0(i)(s) weight: 80(i)(s) width: 100(i)(s) size: 12(f)(s) pixelsize: 12(f)(s) foundry: "Adobe"(s) antialias: FcFalse(s) hintstyle: 3(i)(s) hinting: FcTrue(s) verticallayout: FcFalse(s) autohint: FcFalse(s) globaladvance: FcTrue(s) file: "/usr/share/fonts/X11/75dpi/helvR12.pcf.gz"(s) index: 0(i)(s) outline: FcFalse(s) scalable: FcFalse(s) dpi: 75(f)(s) scale: 1(f)(s) charset: : 0001 7fff 0001: 7fff a4844240 1861c183 e00d ff313fff 0002: cfff 000fffc0 8311 02200020 40007380 3800 3f00efc0 4000 0003: 4000 00b0 1000 001e: 03ff f3f3fcf3 3fcf3cf3 033fcf3f 0020: ff3f0fff 06010047 0010 000e 3260 0021: 0208 00040c04 0022: 02240019 0040 0600 0003c037 (s) lang: aa|af|ast|ay|bi|br|bs|ca|ch|co|cs|cy|da|de|en|eo|es|et|eu|fi|fj|fo|fr|fur|fy|ga|gd|gl|gn|gv|haw|ho|hr|hu|ia|ibo|id|ie|io|is|it|ki|kl|kw|la|lb|lt|lv|mg|mh|mi|mt|nb|nds|nl|nn|no|nr|nso|ny|oc|om|pl|pt|rm|ro|se|sk|sl|sm|sma|smj|smn|so|sq|ss|st|sv|sw|tn|to|tr|ts|ven|vo|vot|wa|wen|wo|xh|yap|zu(s) fontversion: 0(i)(s) fontformat: "PCF"(s) embeddedbitmap: FcTrue(s) decorative: FcFalse(s) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using console-setup's keyboard setup for HAL and xorg input-hotplug
On Wed, 6 Aug 2008, Colin Watson wrote: On Mon, Aug 04, 2008 at 12:36:33PM +0300, Timo Aaltonen wrote: On Fri, 1 Aug 2008, Julien Cristau wrote: On Thu, Jul 31, 2008 at 13:46:07 -0700, Bryce Harrington wrote: Colin and I had a discussion yesterday regarding the idea of reusing the console-setup keyboard settings with the xorg keyboard input-hotplug stuff in HAL. The idea is that this script would be run from xorg-server.postinst. AIUI these settings could be useful for something other than xorg-server (at least in theory), wouldn't it make sense to run this in hal.postinst instead? Discussed this briefly with Martin Pitt, who is the HAL maintainer in Ubuntu. The postinst is somewhat problematic, because it would mean reconfiguring the package whenever the settings have been changed. So, he proposed to run it in the hal initscript. Hacky, but would fix that issue. I don't think there's any need to force console and X keyboard configuration to be in sync. They have been separate since the dawn of time, with X's configuration simply being initialised from the console configuration performed in the installer and then left to go its own way. I think it would be fine to continue this tradition (arguably imperfect though it is) and just copy over console configuration from /etc/default/console-setup to HAL once when the hal package is configured. Actually, as Bryce mentioned, it's already deployed in a way as we discussed in December. HAL ships 10-x11-keymap.fdi which calls a script (debian-setup-keyboard) that uses hal-set-property to set the values when starting HAL. Fedora had a patch for h-s-p which made it work, finally.. t -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [ubuntu-x] Using console-setup's keyboard setup for HAL and xorg input-hotplug
Timo deployed the new input-hotplug config changes today. Please update your intrepid, reboot, and try it out. I've also sketched in some rough docs about how to do configuration of input devices with HAL and xinput (starting about halfway down): https://wiki.ubuntu.com/X/Config Please review for any errors or omissions. Less contrived examples would also be appreciated. Bryce On Wed, Aug 06, 2008 at 01:22:29AM +0100, Colin Watson wrote: > I think it would be fine to continue this tradition (arguably imperfect > though it is) and just copy over console configuration from > /etc/default/console-setup to HAL once when the hal package is > configured. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using console-setup's keyboard setup for HAL and xorg input-hotplug
On Mon, Aug 04, 2008 at 12:36:33PM +0300, Timo Aaltonen wrote: > On Fri, 1 Aug 2008, Julien Cristau wrote: > >On Thu, Jul 31, 2008 at 13:46:07 -0700, Bryce Harrington wrote: > >>Colin and I had a discussion yesterday regarding the idea of reusing the > >>console-setup keyboard settings with the xorg keyboard input-hotplug > >>stuff in HAL. The idea is that this script would be run from > >>xorg-server.postinst. > > > >AIUI these settings could be useful for something other than > >xorg-server (at least in theory), wouldn't it make sense to run this in > >hal.postinst instead? > > Discussed this briefly with Martin Pitt, who is the HAL maintainer in > Ubuntu. The postinst is somewhat problematic, because it would mean > reconfiguring the package whenever the settings have been changed. So, he > proposed to run it in the hal initscript. Hacky, but would fix that issue. I don't think there's any need to force console and X keyboard configuration to be in sync. They have been separate since the dawn of time, with X's configuration simply being initialised from the console configuration performed in the installer and then left to go its own way. I think it would be fine to continue this tradition (arguably imperfect though it is) and just copy over console configuration from /etc/default/console-setup to HAL once when the hal package is configured. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
