Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works
Vincent Lefevre writes: > I've finally found the solution: > > # apt-get install xkbset > $ xkbset -a Thanks. That's useful. But I found an even better solution: apt-cache search xdm (install one of the alternatives) apt-get purge gdm3 This has the extra bonus that XAUTHORITY is back where you expect it to be, and the X server command line is configurable again. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k3xollht@nemi.mork.no
Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works
Julien Cristau writes: > On Fri, Jul 27, 2012 at 02:39:14 +0100, Wookey wrote: > >> A way to confirm if the slowkeys feature is currently engaged would >> allow me to confirm this more directly next time. >> > http://cgit.freedesktop.org/xorg/xserver/commit/?id=4af8e22b1a539778388fe509a7f3a25860a7879c > is in the X server in sid, so the X log should tell you. That's OK, but how do I permanently disable this mis-feature? I am now starting to get pissed enough to be willing to replace whatever part of the system is necessary. I can probably manage better without an X server than without a keyboard... Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hass50fz@nemi.mork.no
Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works
Vincent Lefevre writes: > On 2012-07-20 08:58:57 +0200, Vincent Lefevre wrote: >> So, it would seem that some part of the system would enable SlowKeys >> in my back for one of the keyboards (I recall that when this happens >> while I'm using the USB keyboard, only the USB keyboard is affected, >> not the laptop keyboard). >> >> If there a way to know whether SlowKeys is enabled, for each available >> keyboard? (Note: I'm not using GNOME, and even GNOME would be useless >> because according to what I see on this page, it cannot differentiate >> keyboards.) > > Additional information: > > * SlowKeys can be turned on and off by pressing the Shift key for > at least 10 seconds: > https://bugzilla.redhat.com/show_bug.cgi?id=816764 > I've tried and I confirm that this "works". When several keyboards > are attached, only the keyboard for which the Shift key is pressed > is affected (I suppose that this is expected). Thanks a lot for posting this. I've now hit the bug several times myself over the last few days, and without having read this thread first I would never have known how to get out ot it. And that would have been really annoying given that this typically happens in the middle of some heavy editing session. I would have hated to have to throw away the work and reboot to get the system working again, and I don't think I ever would have figured out the shift key trick. BTW, is it only me, or do you have to hold down the key significantly longer to turn the "feature" off than to turn it on? It certainly feels like it. > * When the bug occurred in my case, I don't think I've pressed Shift > for 10 seconds (well, when I do this, this is in combination with > another key like PageUp / PageDown, but in this case, SlowKeys > switching isn't triggered), at least in most of the cases. In my case it seems to happen most often when I do cut and paste, combining mouse selection with shift + del. I often end up holding down the shift key while selecting and bam... IMNSHO, the hotkey choice is too generic to be acceptable at all. Holding down any single key to silently enable a feature like this is not going to do. I find it somwhat surprising in light of the Ctrl+Alt+Backspace disabling Why couldn't they have used *both* shift keys as a trigger? That would have eliminated all false positives with no drawbacks AFAICS. Anyway, please disable this extremely annoying feature until some safer trigger can be found. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4ryjp3z@nemi.mork.no
Bug#602207: backported upstream fix
Although this is far too late for the squeeze release, I assume that
fixing this bug in a later point release might be of interest. The
upstream fix does not apply cleanly to 2.13.0 so I have backported it.
Backport patch is attached.
The second patch is a straight cherry-pick of 537fa55e. This is
necessary to avoid introducing a regression. I've not combined the
patches to keep as much as possible of upstream history.
I have succcessfully tested and verified this fix on top of the Debian
package version 2:2.13.0-5. Please consider it for squeeze.1
Bjørn
>From e40735144642766f25b0f916ff3532bfe0b79617 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B8rn=20Mork?=
Date: Sat, 15 Jan 2011 14:01:19 +0100
Subject: [PATCH 1/3] Don't replace the scanout bo through PutImage
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As the bo may be pinned for either use by the scanout or through sharing
with another application, under those circumstances we cannot replace
the bo itself but must force the blit for PutImage.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31367
Reported-and-tested-by: Bjørn Mork
Signed-off-by: Chris Wilson
[backport of commit 53fbc9f1]
Signed-off-by: Bjørn Mork
---
src/intel.h |1 +
src/intel_dri.c | 26 +++---
src/intel_uxa.c |5 +++--
3 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/src/intel.h b/src/intel.h
index b816aeb..93a3524 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -169,6 +169,7 @@ struct intel_pixmap {
uint8_t tiling;
int8_t busy :2;
int8_t batch_write :1;
+ int8_t pinned :1;
};
#if HAS_DEVPRIVATEKEYREC
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 9804272..49d83da 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -71,6 +71,22 @@ typedef struct {
unsigned int attachment;
} I830DRI2BufferPrivateRec, *I830DRI2BufferPrivatePtr;
+static uint32_t pixmap_flink(PixmapPtr pixmap)
+{
+ struct intel_pixmap *priv = intel_get_pixmap_private(pixmap);
+ uint32_t name;
+ dri_bo *bo;
+
+ if (priv == NULL || priv->bo == NULL)
+ return 0;
+
+ if (dri_bo_flink(bo, &name) != 0)
+ return 0;
+
+ priv->pinned = 1;
+ return name;
+}
+
#if DRI2INFOREC_VERSION < 2
static DRI2BufferPtr
@@ -81,10 +97,9 @@ I830DRI2CreateBuffers(DrawablePtr drawable, unsigned int *attachments,
ScrnInfoPtr scrn = xf86Screens[screen->myNum];
intel_screen_private *intel = intel_get_screen_private(scrn);
DRI2BufferPtr buffers;
- dri_bo *bo;
- int i;
I830DRI2BufferPrivatePtr privates;
PixmapPtr pixmap, pDepthPixmap;
+ int i;
buffers = calloc(count, sizeof *buffers);
if (buffers == NULL)
@@ -144,8 +159,7 @@ I830DRI2CreateBuffers(DrawablePtr drawable, unsigned int *attachments,
privates[i].pixmap = pixmap;
privates[i].attachment = attachments[i];
- bo = intel_get_pixmap_bo(pixmap);
- if (bo == NULL || dri_bo_flink(bo, &buffers[i].name) != 0) {
+ if ((buffers[i].name = pixmap_flink(pixmap)) == 0) {
/* failed to name buffer */
screen->DestroyPixmap(pixmap);
goto unwind;
@@ -190,7 +204,6 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int attachment,
ScrnInfoPtr scrn = xf86Screens[screen->myNum];
intel_screen_private *intel = intel_get_screen_private(scrn);
DRI2Buffer2Ptr buffer;
- dri_bo *bo;
I830DRI2BufferPrivatePtr privates;
PixmapPtr pixmap;
@@ -252,8 +265,7 @@ I830DRI2CreateBuffer(DrawablePtr drawable, unsigned int attachment,
privates->pixmap = pixmap;
privates->attachment = attachment;
- bo = intel_get_pixmap_bo(pixmap);
- if (bo == NULL || dri_bo_flink(bo, &buffer->name) != 0) {
+ if ((buffer->name = pixmap_flink(pixmap)) == 0) {
/* failed to name buffer */
screen->DestroyPixmap(pixmap);
free(privates);
diff --git a/src/intel_uxa.c b/src/intel_uxa.c
index ef4c553..b3d8d31 100644
--- a/src/intel_uxa.c
+++ b/src/intel_uxa.c
@@ -767,7 +767,8 @@ static Bool intel_uxa_put_image(PixmapPtr pixmap,
} else {
ScreenPtr screen = pixmap->drawable.pScreen;
- if (x == 0 && y == 0 &&
+ if (!priv->pinned &&
+ x == 0 && y == 0 &&
w == pixmap->drawable.width &&
h == pixmap->drawable.height)
{
@@ -1263,7 +1264,7 @@ void intel_uxa_create_screen_resources(ScreenPtr screen)
if (bo != NULL) {
PixmapPtr pixmap = screen->GetScreenPixmap(screen);
intel_set_pixmap_bo(pixmap, bo);
- intel_get_pixmap_private(pixmap)->busy = 1;
+ intel_get_pixmap_private(pixmap)->pinned = 1;
screen->ModifyPixmapHeader(pixmap,
scrn->virtualX,
scrn->virtualY,
--
1.7.2.3
>From 20f80989044dee581e97ae33ffd3d3789e8dfeff Mon Sep 17 00:00:00 2001
From: Chris Wilson
Date: Sun, 2 Jan 2011 09:06:28 +
Subject: [PATCH 2/3] dri: Fix the use of the uninitialised bo for flink
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bi
Bug#602207: xserver-xorg-video-intel: Swiching SDL window to fullscreen causes black screen
I believe I've found where the problem was introduced, but I don't have a proper solution. I'd appreciate it if any of you are able to code up thing to replace the buggy uxa_put_image code. The problem was introduced in commit 19d8c0cf "uxa: PutImage acceleration" which can be verified by checking out 2.10.0 and reverting just this commit. It does not revert cleanly in later versions but the attached patch against 2.12.0 will have the same effect, leaving some dead code around. Unfortunately, this quickfix will also impact performance. So if anyone is able to fix the i830_uxa_put_image() code instead, that would be preferred... Bjørn >From baf201d496e46dd8ec6f687bcacde02dfa0df4b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B8rn=20Mork?= Date: Thu, 4 Nov 2010 15:51:55 +0100 Subject: [PATCH] testing whether removing put_image will fix the black screen problem MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Bjørn Mork --- src/i830_uxa.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/src/i830_uxa.c b/src/i830_uxa.c index 61e857f..c34ba18 100644 --- a/src/i830_uxa.c +++ b/src/i830_uxa.c @@ -1157,7 +1157,6 @@ Bool i830_uxa_init(ScreenPtr screen) } /* PutImage */ - intel->uxa_driver->put_image = i830_uxa_put_image; intel->uxa_driver->get_image = i830_uxa_get_image; intel->uxa_driver->prepare_access = i830_uxa_prepare_access; -- 1.7.2.3
Bug#602207: xserver-xorg-video-intel: Swiching SDL window to fullscreen causes black screen
Cyril Brulebois writes: > Christian Henz (03/11/2010): >> I wrote a small test program that exposes this behaviour. One thing >> to note is that the problem only occurs if the program in question >> is running at the native screen resolution (1680x1050 in my case). >> >> So for example >> 1024x768/fullscreen -> 1024x768/window -> 1024x768/fullscreen >> works here, but >> 1680x1050/fullscreen -> 1680x1050/window -> 1680x1050/fullscreen >> does not. Very useful! Thanks. BTW, I found a way out of the black screen when using QEMU/KVM: If I switch to text mode while in the SDL fullscreen session (e.g. by pressing ctrl-alt-1 to switch to the "serial0" console), and then switch out of fullscreen again, the black screen is gone and the X server can be used again. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyjy7mio@nemi.mork.no
Bug#602207: xserver-xorg-video-intel: Swiching SDL window to fullscreen causes black screen
Julien Cristau writes: > On Tue, Nov 2, 2010 at 15:09:49 +0100, Bjørn Mork wrote: > >> - first time the client window is switched to fullscreen the backlight dims >> to a very >> low setting. The backlight can be adjusted up again using ordinary >> backlight controls >> so this is not a serious problem. It is however, a regression from >> 2:2.9.1-4 and I >> mention it because I suspect it is related to the next symptom. > > This sounds like 600405, can you try the patch there and see if it also > fixes your second symptom? Thanks for the pointer. The patch fixes the first issue, as expected. But unfortunately it does not fix the second. So much for the theory that these were related. But I guess it is useful to rule that out. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y69a7msi@nemi.mork.no
Bug#576719: xserver-xorg-input-synaptics: multitouch emulation stopped working
ow...@bugs.debian.org (Debian Bug Tracking System) writes: > Not a bug, the x11_options in udev is now ignored. Use xorg.conf to > set options, using an InputClass section with e.g. the MatchIsTouchpad > option (see the xorg.conf manpage and > https://fedoraproject.org/wiki/Input_device_configuration). That's great news! Thanks But this needs to go into NEWS.Debian. In fact I looked there to see if any such changes were to be expected in this version, since I knew you've mentioned this before as the long-term development direction. Anyway, how about a transitional warning message if you detect any x11_options environment variable? I can produce a patch if you want. It should be trivial. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx2ze2i3.fsf...@nemi.mork.no
Bug#576719: udev backwards compatibility
tags 576719 + patch
thanks
I also ran into this problem after upgrading xserver-xorg-core to
version 2:1.7.6-2
I'm using a customized udev rule to set two options for the touchpad on
my laptop, using "x11_options.*" environment variables:
bj...@nemi:~$ udevadm info --query=all
--path=/devices/platform/i8042/serio1/input/input6/event6
P: /devices/platform/i8042/serio1/input/input6/event6
N: input/event6
S: char/13:70
S: input/by-path/platform-i8042-serio-1-event-mouse
E: UDEV_LOG=3
E: DEVPATH=/devices/platform/i8042/serio1/input/input6/event6
E: MAJOR=13
E: MINOR=70
E: DEVNAME=/dev/input/event6
E: SUBSYSTEM=input
E: ID_INPUT=1
E: ID_INPUT_MOUSE=1
E: ID_INPUT_TOUCHPAD=1
E: ID_SERIAL=noserial
E: ID_PATH=platform-i8042-serio-1
E: x11_driver=synaptics
E: x11_options.SHMConfig=on
E: x11_options.TapButton1=1
E: DMI_VENDOR=LENOVO
E: DEVLINKS=/dev/char/13:70
/dev/input/by-path/platform-i8042-serio-1-event-mouse
AFAIK, this is currently the only way to configure the synaptics
driver, and I do need at least the TapButton1 configuration.
The attached patch enhances the udev backwards compatibilty by adding
any "x11_options." prefixed option to the config. I really don't have a
clue whether this is a good idea or not, but it does at least restore
the previous behaviour for me. YMMV
Bjørn
pgp237BgTtL2m.pgp
Description: PGP signature
From: Bjørn Mork
Subject: Keep looking for x11_options in udev for now
Our drivers don't ship xorg.conf.d snippets for now, so keep using
x11_options from udev in the transition period.
Index: xorg-server/config/udev.c
===
--- xorg-server.orig/config/udev.c
+++ xorg-server/config/udev.c
@@ -36,6 +36,7 @@
#include "os.h"
#define UDEV_XKB_PROP_KEY "xkb"
+#define UDEV_X11OPTIONS_KEY "x11_options."
static struct udev_monitor *udev_monitor;
@@ -120,6 +121,10 @@
add_option(&options, "xkb_options", value);
} else if (!strcmp(key, "x11_driver")) {
add_option(&options, "driver", value);
+ } else if (!strncasecmp(key, UDEV_X11OPTIONS_KEY,
+sizeof(UDEV_X11OPTIONS_KEY) - 1)) {
+tmp = key + sizeof(UDEV_X11OPTIONS_KEY) - 1;
+ add_option(&options, tmp, value);
} else if (!strcmp(key, "ID_VENDOR")) {
attrs.vendor = value;
} else if (!strcmp(key, "ID_INPUT_KEY")) {
Bug#564318: xserver-xorg-video-intel: same problem with latest Debian kernel (2.6.32-5)
Bjørn Mork writes: > I see that I have the same issue of vesafb loaded befor the Intel fb. Is this > the problem? If so, then I guess either xserver-xorg-video-intel or the > kernel should prevent it. I've not done anything to force vesafb AFAIK Well, not intentionally at least. Typically, right after posting this it struck me: I had "vga=792" on my kernel command line as a leftover since forever... That's what screwed up. I guess you need to add /proc/cmdline to your reportbug script now :-) Something should also probably be done to warn lusers like myself of this problem when auto-enabling KMS. Looking for VESA modes on the command line maybe? Happy now. Just need to find out how I enable the nice native resolution from boot. I guess it must be documented somewhere... Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1
Julien Cristau writes: > I'd really prefer not to do that. Configuring stuff in hal or udev is > just a stopgap until X grows a way to handle hotplugged devices in > xorg.conf (which will happen with xserver 1.8), so I think we shouldn't > recommend/document this as the way to go. Plus we have tools and > protocol for runtime configuration anyway. OK. I agree that documenting this workaround should be avoided if it is going to be temporary. It would just add to the confusion. I didn't realize that using udev for storing config was just a stopgap. That fact should probably go into the README. > (See > http://who-t.blogspot.com/2010/01/new-configuration-world-order.html for > a description of the way things are going) Looks good! I've always fealt that this kind of configuration belonged to the X server and had little to do with hal/udev. Adding the necessary glue to allow a mix of auto-device discovery and xorg.conf snippets sounds just like it was taken from my wishlist :-) Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564211: xserver-xorg-input-synaptics: Lost tapping after upgrading to 1.2.1-1
Julien Cristau writes:
> On Fri, Jan 8, 2010 at 13:59:50 +0100, Bjørn Mork wrote:
>
>> Just did an upgrade:
>> 2010-01-08 11:04:22 upgrade xserver-xorg-input-synaptics 1.2.0-2 1.2.1-1
>>
>> and lost tapping in the process. The buttons still work, but I'm kind
>> of accustomed to use tapping for most of my clicking activities.
>>
>> Any advice on where to look is appreciated.
>>
> How did you configure tapping?
I used a hal fdi file as per the previous recommendations. Which I see
still are in the docs. This needs to be fixed and some note about udev
rules should be added to NEWS.
Right after sending the bug report, I realized that this is just another
example of the hal => udev transition biting users. Could we please try
to make this transition as seemless as possible, attempting to keep any
prior configuration if possible?
I hacked up this, which probably can't be used directly, but should work
as an example of how to migrate configuration from hal to udev. It will
write a new udev rule file, which could be saved as
/etc/udev/rules.d/66-xorg-synaptics.rules to override the system default:
#!/usr/bin/perl
use strict;
use warnings;
use Net::DBus;
# hardcoded filename
my $baserule = '/lib/udev/rules.d/66-xorg-synaptics.rules';
# regex telling us after which statement we'd like to insert the options
my $optionsplit = qr/^ENV\{x11_driver\}/;
# read the system rule file
open(F, $baserule) || die "Cannot open $baserule: $!\n";
my @before;
my @after;
my $ra = \...@before;
while () {
push(@$ra, $_);
$ra = \...@after if /$optionsplit/;
}
close(F);
# connect to system bus
my $bus = Net::DBus->system;
# Get a handle to the HAL service
my $hal = $bus->get_service("org.freedesktop.Hal");
# Get the device manager
my $manager = $hal->get_object("/org/freedesktop/Hal/Manager",
"org.freedesktop.Hal.Manager");
my @migrated;
# Get a list of all touchpads
foreach my $dev (@{$manager->FindDeviceByCapability("input.touchpad")}) {
my $tp = $hal->get_object($dev, "org.freedesktop.Hal.Device");
my $props = $tp->GetAllProperties();
if (my @opts = grep { s/^input\.x11_options\.// } keys %$props) {
warn "Migrating device specific x11_options ", join(',', @opts)," for
$props->{'info.product'}\n";
push(@migrated, "ATTRS{name}==\"$props->{'info.product'}\", \\\n");
push(@migrated, join(", \\\n", map { " ENV\{x11_options.$_\}=\"".
$props->{"input.x11_options.$_"} .'"' } @opts));
push(@migrated, "\n\n");
}
}
if (@migrated) {
print @before;
print "\n# automatically added based on hal:\n";
print @migrated;
print @after;
} else {
warn "No touchpad with x11_options found in hal - private udev rule
unnecessary\n";
}
Bjørn
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: console-setup + X = broken console
Julien Cristau writes: > On Mon, May 11, 2009 at 14:38:35 -0500, Adam Majer wrote: >> David Nusinow wrote: >> > Please see http://wiki.debian.org/XStrikeForce/InputHotplugGuide for the >> > rationale and #515214 for more info. >> >> That is great, yet it does nothing for me except change fonts. I've read >> the bug report, and it is just people complaining about Hal and >> console-setup dependencies. >> > If there's no way to tell console-setup to not change fonts, then that > probably can be fixed. That doesn't mean we should drop the dependency. It's already fixed: console-setup (1.33) unstable; urgency=medium [ Colin Watson ] * Remove mention of long-dead devfs (closes: #524765). * Don't load a font if FONTFACE, FONTSIZE, and FONT are all unset. >> Moving these packages to Recommends DOES NOT mean you need to support >> input definitions in xorg.conf! >> > It means that installs without hal and console-setup ought to work. > They don't. I assume you meant that they don't work out of the box? They can certainly be made to work, given configuration. Systems working out of the box by default are nice, but I fail to see why the auto-configuration should be forced onto the administrators. It could be made optional and still kept as default. > So I don't think moving these packages to recommends would > do anyone any good (except for the warm fuzzy feeling for some whiners, > which I'm happy to ignore). Moving hal and console-setup to Recommends would not change anything for a default installation, but would provide a choice for those whiners. It's a win-win. Bjørn -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
