Bug#436536: xserver-xorg-video-ati: Xorg does not start on a PowerMacintosh 9600/300 with an ATI Mach64 PCI video card
On 08/ago/07, at 08:53, Brice Goglin wrote: Could you try xserver-xorg-video-ati 1:6.6.193-1 currently in experimental? It is a very recent snapshot of the upstream git repository. But, you'll have to upgrade xserver-xorg-core and several libraries to testing/Lenny. I'll try that right away, but it will take me a few days to get all the dependencies right -- the testing machine has no internet connection :-( I'll let you know as soon as I have some results. Thanks, Damiano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430885: xserver-xorg-video-intel: new intel driver doesn't support all modes of i810 driver
Itai Seggev wrote: > The output to the first two commands is below. Did you forget to paste it ? > I didn't know about > xrandr and using it to resize. When I tried the command above > involving --mode, I got a usage message but that's it. You need to upgrade xbase-clients to 7.2 (in testing). > I'll be losing > access to this machine in a few days (new job), so I won't be able to > help with tings for much longer. > Ok, if you're not able to test/debug/help things anymore for this bug, we'll probably close it until somebody else meets it. But I am pretty confident that your problem is just about the preferred mode of your monitor not being the largest one, and xrandr should allow to change it after starting X. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430885: xserver-xorg-video-intel: new intel driver doesn't support all modes of i810 driver
On Thu, Aug 09, 2007 at 12:44:56AM +0200, Brice Goglin wrote: > Drew Parsons wrote: > > Your X log reports that the server knows about your desired mode: > > > > (II) intel(0): Modeline "1280x1024"x85.0 157.50 1280 1344 1504 1728 > > 1024 1025 1028 1072 +hsync +vsync (91.1 kHz) > > (II) intel(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 > > 1025 1028 1066 +hsync +vsync (80.0 kHz) > > (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 > > 1025 1028 1066 +hsync +vsync (64.0 kHz) > > > > Do you have xrandr 1.2 installed? What does "xrandr" say? Does > > "xrandr --verbose" show the modes listed above? Did you select your > > mode with "xrandr --mode 1280x1024"? > > Work is ongoing in the server to make xorg.conf redundant altogether. > > One thing you could try is deleting xorg.conf completely and seeing > > what kind of success you get. Or alternatively delete the Modes lines > > from the Screen section. > > > > Hi Itai, > > Any news about this? Could you reply to what Drew requested above? It > would for instance let us know whether your monitor has a preferred > mode, which might explain why the new driver chooses one mode instead of > another. > > Thanks, > Brice Sorry, I thought I had replied to this... The output to the first two commands is below. I didn't know about xrandr and using it to resize. When I tried the command above involving --mode, I got a usage message but that's it. I'll be losing access to this machine in a few days (new job), so I won't be able to help with tings for much longer. -- Itai Seggev Visiting Assistant ProfessorOffice: Lewis 121A Department of Physics and Astronomy Phone: +1-662-915-3887 University of Mississippi Fax: +1-662-915-5045 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: retitle 430432 to lockup when running GL apps with beryl on i945GM
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.6 > retitle 430432 lockup when running GL apps with beryl on i945GM Bug#430432: libdrm2: i915 driver problem Changed Bug title to `lockup when running GL apps with beryl on i945GM' from `libdrm2: i915 driver problem'. > 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]
Processed: retitle 430819 to fluxbox aborts on upgrade to xserver 1.3, reassign 430819 to xserver-xorg-core ...
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.6 > retitle 430819 fluxbox aborts on upgrade to xserver 1.3 Bug#430819: xserver-xorg: update breaks X with spurious AIGLX error Changed Bug title to `fluxbox aborts on upgrade to xserver 1.3' from `xserver-xorg: update breaks X with spurious AIGLX error'. > # might be a fluxbox bug, we'll see > reassign 430819 xserver-xorg-core Bug#430819: fluxbox aborts on upgrade to xserver 1.3 Bug reassigned from package `xserver-xorg' to `xserver-xorg-core'. > tags 430819 moreinfo Bug#430819: fluxbox aborts on upgrade to xserver 1.3 There were no tags set. Tags added: moreinfo > 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#430819: retitle 430819 to fluxbox aborts on upgrade to xserver 1.3, reassign 430819 to xserver-xorg-core ...
# Automatically generated email from bts, devscripts version 2.10.6 retitle 430819 fluxbox aborts on upgrade to xserver 1.3 # might be a fluxbox bug, we'll see reassign 430819 xserver-xorg-core tags 430819 moreinfo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430885: xserver-xorg-video-intel: new intel driver doesn't support all modes of i810 driver
Drew Parsons wrote: > Your X log reports that the server knows about your desired mode: > > (II) intel(0): Modeline "1280x1024"x85.0 157.50 1280 1344 1504 1728 > 1024 1025 1028 1072 +hsync +vsync (91.1 kHz) > (II) intel(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) intel(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 > 1025 1028 1066 +hsync +vsync (64.0 kHz) > > Do you have xrandr 1.2 installed? What does "xrandr" say? Does > "xrandr --verbose" show the modes listed above? Did you select your > mode with "xrandr --mode 1280x1024"? > > > Work is ongoing in the server to make xorg.conf redundant altogether. > One thing you could try is deleting xorg.conf completely and seeing > what kind of success you get. Or alternatively delete the Modes lines > from the Screen section. > Hi Itai, Any news about this? Could you reply to what Drew requested above? It would for instance let us know whether your monitor has a preferred mode, which might explain why the new driver chooses one mode instead of another. Thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434439: xfonts-encodings copyright statement is bogus
On Mon, Jul 23, 2007 at 23:02:57 +0200, Juliusz Chroboczek wrote: > In /usr/share/doc/xfonts-encodings/copyright, I read, > > > Copyright 2002-2004 Red Hat Inc., Durham, North Carolina. > > All Rights Reserved. > > Considering that I personally generated most of the files contained in > this package, and that I've never been to North Carolina, of all places, > this would appear to be incorrect. Could you please replace this file > with the one from > > git.freedesktop.org/git/xorg/font/encodings/COPYING > > I've just modified it, so please make sure you git pull first. > Or you could release it :) http://wiki.x.org/wiki/Development/Documentation/ReleaseHOWTO Cheers, Julien signature.asc Description: Digital signature
[bts-link] source package xserver-xorg-input-penmount
# # bts-link upstream status pull for source package xserver-xorg-input-penmount # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED # remote status report for #422678 # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 # * remote status changed: REOPENED -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 422678 + fixed-upstream usertags 422678 - status-REOPENED usertags 422678 + status-RESOLVED resolution-FIXED thanks
[bts-link] source package xserver-xorg-video-ati
# # bts-link upstream status pull for source package xserver-xorg-video-ati # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #435040 # * https://bugs.freedesktop.org/show_bug.cgi?id=11899 # * remote status changed: (?) -> NEW usertags 435040 + status-NEW thanks
[bts-link] source package xserver-xorg-video-intel
# # bts-link upstream status pull for source package xserver-xorg-video-intel # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user [EMAIL PROTECTED] # remote status report for #434297 # * https://bugs.freedesktop.org/show_bug.cgi?id=11366 # * remote status changed: (?) -> RESOLVED # * remote resolution changed: (?) -> FIXED usertags 434297 + status-RESOLVED resolution-FIXED thanks
Processed: [bts-link] source package xserver-xorg-input-penmount
Processing commands for [EMAIL PROTECTED]: > # > # bts-link upstream status pull for source package xserver-xorg-input-penmount > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user [EMAIL PROTECTED] Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Tags were: sid lenny Tags added: fixed-upstream > usertags 422678 - status-REOPENED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: status-REOPENED. Usertags are now: . > usertags 422678 + status-RESOLVED resolution-FIXED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) There were no usertags set. Usertags are now: resolution-FIXED status-RESOLVED. > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Tags were: fixed-upstream sid lenny Tags added: fixed-upstream > usertags 422678 - status-REOPENED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > usertags 422678 + status-RESOLVED resolution-FIXED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Tags were: fixed-upstream sid lenny Tags added: fixed-upstream > usertags 422678 - status-REOPENED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > usertags 422678 + status-RESOLVED resolution-FIXED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Tags were: fixed-upstream sid lenny Tags added: fixed-upstream > usertags 422678 - status-REOPENED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > usertags 422678 + status-RESOLVED resolution-FIXED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Tags were: fixed-upstream sid lenny Tags added: fixed-upstream > usertags 422678 - status-REOPENED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > usertags 422678 + status-RESOLVED resolution-FIXED Bug#422678: FTBFS: ../../src/xf86PM.c:389: error: 'TS_Raw' undeclared (first use in this function) Usertags were: resolution-FIXED status-RESOLVED. Usertags are now: resolution-FIXED status-RESOLVED. > # remote status report for #422678 > # * https://bugs.freedesktop.org/show_bug.cgi?id=10262 > # * remote status changed: REOPENED -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 422678 + fixed-upstream Bug#422678: FTBFS: ../../src/xf86P
Bug#426286: marked as done (Erratic Caps lock and Ctrl key behavior)
Your message dated Wed, 08 Aug 2007 22:00:47 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#426286: Erratic Caps lock and Ctrl key behavior has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: xserver-xorg-input-kbd Version: 1:1.1.0-4 On a Thinkpad X40 keyboard - tried with both a standard american English keyboard and german Deutsch one - there is something extremely bizarre going on that seem to involve Caps Lock and Ctrl keys. Intermittently the Caps lock seems to get activated even though the Caps Lock LCD indicator light is off. Normally to fix it, shift + a character must be pressed, after which releasing the Shift key will return keys to lowercase. More troubling is that from time to time somehow the Ctrl key seems to get stuck on. This can be extremely dangerous as subsequent keypresses are now Ctrl-key combinations and have the potential to kill processes, shut down terminals, etc. I still do not know how Ctrl key gets untoggled in this state, but it is not by pressing the Ctrl key. When this problem initially occurred I thought perhaps there was some severe problem with the keyboard. But changing the keyboard made no difference. I also completely re-installed Debian but the problem persisted. The problem does not, however, occur under non-Debian. --- End Message --- --- Begin Message --- Version: 1:1.2.0-1+1.2.1 Daniel O'Neill wrote: > So wrote Brice Goglin on Wednesday, 8 August 2007: > >> Hi, >> >> Does this bug still happen with latest xserver-xorg-input-kbd (1.2.0 in >> testing) and xserver-xorg-core (2:1.3.0.0.dfsg-11) ? >> >> Brice >> > > > I have not noticed the problem in a while. I guess this can be closed. > Thank you for following-up! > And thanks for replying quickly! Marking as fixed in xserver-xorg-input-kbd since it is likely the one fixing this issue. Brice --- End Message ---
Bug#419986: server lockups related to dri
Olaf Till wrote: > Hi Brice, > > the problem persists after upgrading to > > - libc6_2.5-9+b1_i386.deb (and new tzdata) (testing) > - libdrm2_2.3.0-4_i386.deb (testing) > - libgl1-mesa-dri_6.5.2-5_i386.deb (and new ligl1-mesa-gly) (unstable) > - xserver-xorg-core_1.3.0.0.dfsg-6_i386.deb (unstable) > > (ignoring an unmet dependency of xserver-xorg-core on a newer > libgcc1). > > I am sorry, I know that you spend a lot of your spare time for these > problems, but I will not be able to help you much further in the next > time, I could not manage not to delay other things too much ... > Hi Olaf, No good news about this bug? There are some new mesa updates in experimental if you want to try them (6.5.3 right now, 7.0.1 soon). Something else (and easy) you could try is adding Option "BusType" "PCI" to the "Device" section of your xorg.conf, it seems AGP bridges are often buggy, so using a plain PCI mode might help. Other random idea: changing the AGP mode in the BIOS could possibly help too. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#429432: xserver-xorg: [ati/r128] 1152x768 can no longer be used on PowerBook, incorrect display
Vincent Lefevre wrote: > Taking the modeline from > > http://forums.gentoo.org/viewtopic.php?t=469455 > > solved the problem, but this doesn't explain why the old one no longer > works. > Does xserver-xorg-video-ati 6.6.193 (in experimental) help ? thanks, Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426286: Erratic Caps lock and Ctrl key behavior
So wrote Brice Goglin on Wednesday, 8 August 2007: > > Hi, > > Does this bug still happen with latest xserver-xorg-input-kbd (1.2.0 in > testing) and xserver-xorg-core (2:1.3.0.0.dfsg-11) ? > > Brice I have not noticed the problem in a while. I guess this can be closed. Thank you for following-up! -- Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426286: Erratic Caps lock and Ctrl key behavior
Hi, Does this bug still happen with latest xserver-xorg-input-kbd (1.2.0 in testing) and xserver-xorg-core (2:1.3.0.0.dfsg-11) ? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 405859 to libgl1-mesa-dri, retitle 405859 to GLUT_ALPHA does not work with DRI ...
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.6 > reassign 405859 libgl1-mesa-dri Bug#405859: xserver-xorg-video-mga: freeglut error if there's no Virtual line in xorg config file Bug reassigned from package `xserver-xorg-video-mga' to `libgl1-mesa-dri'. > retitle 405859 GLUT_ALPHA does not work with DRI Bug#405859: xserver-xorg-video-mga: freeglut error if there's no Virtual line in xorg config file Changed Bug title to `GLUT_ALPHA does not work with DRI' from `xserver-xorg-video-mga: freeglut error if there's no Virtual line in xorg config file'. > severity 405859 wishlist Bug#405859: GLUT_ALPHA does not work with DRI 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#352153: marked as done (ITP: xserver-xgl -- OpenGL Backed X Server)
Your message dated Wed, 08 Aug 2007 11:59:28 -0600 with message-id <[EMAIL PROTECTED]> and subject line WNPP bug closing has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: wnpp Severity: wishlist Owner: David Nusinow <[EMAIL PROTECTED]> * Package name: xserver-xgl Version : 1.0.1 Upstream Author : X.Org <[EMAIL PROTECTED]> * URL : http://www.freedesktop.org * License : MIT/X Description : OpenGL Backed X Server This is an X server that sits on top of any GLX-capable X server and processes X events using OpenGL. This allows it to take advantage of hardware acceleration provided you have the drivers available. This package is actually built from the xserver-xorg-core package (hence the version number) and thus will be maintained by the X Strike Force. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) --- End Message --- --- Begin Message --- Hello, This is an automatic mail sent to close the ITP you have reported or are involved with. Your ITP wnpp bug is being closed because of the following reasons: - It is, as of today, older than 365 days. - It hasn't had any activity recently. As this is an automatic procedure, it could of course have something wrong and probably it would be closing some bugs that are not intended by owners and submitters (like you) to be closed, for example if the ITP is still of your interest, or there has been some kind of activity around it. In that case, please reopen the bug, do it, DO IT NOW! (I don't want to be blamed because of mass closing and not let people know that they can easily reopen their bugs ;-). To re-open it, you simply have to mail [EMAIL PROTECTED] with a body text like this: reopen 352153 stop Further comments on the work done in the bug sent to [EMAIL PROTECTED] would be truly welcomed. Anyway, if you have any kind of problems when dealing with the BTS, feel free to contact me and I'd be more than happy to help you on this: <[EMAIL PROTECTED]>. A similar process is being applied to other kind of wnpp bugs. Thanks for your cooperation, -- David Moreno Garza <[EMAIL PROTECTED]>. --- End Message ---
Bug#422168: xserver-xorg-core: xv compresses movies to half of the screen
Jiří Paleček wrote: > On Fri, 04 May 2007 08:39:30 +0200, Brice Goglin > <[EMAIL PROTECTED]> wrote: > >> Jiri Palecek wrote: >>> Package: xserver-xorg-core >>> Version: 2:1.3.0.0.dfsg-3 >>> Severity: normal >>> >>> Hello, >>> >>> when I play movies through xv, either in kaffeine or mplayer, they are >>> compressed >>> to the left half of the viewport, either fullscreen or window. >>> Interesting thing is, >>> that restarting X sometimes solves the problem. Do you know when this problem started to occur ? After upgrading xserver-xorg-core to 1.3 ? Does the problem go away if you downgrade to 1.1 in Etch ? Or if you downgrade xserver-xorg-video-ati to 6.6.3 (in testing) or upgrade to 6.6.193 (in experimental) ? Brice
Processed: bug 435040 is forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=11899
Processing commands for [EMAIL PROTECTED]: > # Automatically generated email from bts, devscripts version 2.10.6 > forwarded 435040 https://bugs.freedesktop.org/show_bug.cgi?id=11899 Bug#435040: xserver-xorg-video-ati: switching VT from console to X freezes computer with X22 (Radeon Mobility M6 LY) Noted your statement that Bug has been forwarded to https://bugs.freedesktop.org/show_bug.cgi?id=11899. > 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]
Re: xorg-server: Changes to 'debian-experimental'
On Fri, Aug 3, 2007 at 02:00:45 +0200, Samuel Thibault wrote: > Hi, > > Julien Cristau, le Thu 02 Aug 2007 00:43:49 +0200, a écrit : > > I successfully built xorg-server 2:1.3.99.0-1, and.. it seems to run > > fine > > Seems to work fine on hurd-i386 too, except that > > - the libhal-dev dependency should be [!hurd-i386]: we're far from > having hal working on the Hurd. Thanks, will fix. > - the mesa-swx11-source build-dep is (>> 7.0.1~rc2-1), but even the > debian-experimental branch doesn't have a version greater that this, > was it intended to be >= instead of >>? > No, the build-dep is correct, some patches needed in mesa are in 7.0.1 but not in rc2. But that's in the DRI stuff, which is probably why you didn't notice on the hurd. Cheers, Julien signature.asc Description: Digital signature
Bug#436488: xserver-xorg: Addscreen/screeninit failed for driver 0
On 8/7/07, Brice Goglin <[EMAIL PROTECTED]> wrote: > reassign 436488 xserver-xorg-video-i810 > found 436488 2:1.7.2-4 > severity 436488 normal > thank you > > > > Lucas S wrote: > > I have installed the debian etch from a netinstall cd. Stable40r0. > > The gui mode of installation has worked but after selecting to install > > desktop and standard installtion the xserver is not able to start. > > > > Your board might not be supported by the i810 driver in Etch. You should > upgrade to Debian testing (xserver-xorg-core 2:1.3.0.0.dfsg-11 and > xserver-xorg-video-intel 2:2.1.0-1). Unfortunately this will be a production server in 48h so I am not able to use testing. > > > (EE) GARTInit: Unable to open /dev/agpgart (No such file or directory) > > (WW) I810(0): /dev/agpgart is either not available, or no memory is > > available > > > > Either the kernel agpgart and intel_agp modules are not loaded or they > do not support your board. > > > (II) I810(0): Initial framebuffer allocation size: 7680 kByte > > (EE) I810(0): Failed to allocate framebuffer. Is your VideoRAM set too low > > ?? > > > > This should be fixed in testing. Are there any plans to include these two version of the program into stable anytime soon? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#430498: xserver-xorg-video-intel: Occasional black screen exiting X
On 8/7/07, Brice Goglin <[EMAIL PROTECTED]> wrote: > Does it still happen with xserver-xorg-video-intel 2:2.1.0-1 ? It doesn't happen in 2:2.1.0-2 at least. Thanks for the followup! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436271: PS/2 mouse not working
On Wed, Aug 08, 2007 at 01:07:23PM +0200, Brice Goglin wrote: > Adrian Mariano wrote: > > When I first installed, the mouse was on the ps/2 port. The > > configuration that was supplied by the installer was > > > > Section "InputDevice" > > Identifier "Configured Mouse" > > Driver "mouse" > > Option "CorePointer" > > Option "Device""/dev/input/mice" > > Option "Protocol" "ImPS/2" > > Option "Emulate3Buttons" "true" > > EndSection > > > > That's the default config provided by the installer. > > > The mouse did not work. I moved the mouse from the ps/2 port to the > > USB port and it worked fine. > > > > Then I tried changing /dev/input/mice to /dev/psaux. The mouse WORKED > > FINE with this setup. > > So PS/2 on /dev/psaux worked once. Then it would be a kernel problem or so. > > But you said earlier that pluging on PS/2 did not generate any character > in "cat /dev/psaux" or "cat /dev/input/mice". This needs to be > clarified. Either /dev/psaux works (and generates characters) or it > doesn't at all. > > > Is it possible that some action (e.g. reboot) is necessary to cause > > the kernel to realize there is a mouse on the ps/2 port? > > > > I don't think so. > > Please check your BIOS in case there some config for the PS/2 port. And > check whether PS/2 works in other Linux/OS if you can. This is a brand new machine that has only the one OS installed. I tried booting Knoppix and it wouldn't boot. So I don't think we're going to see other OS results. After observing that /dev/input/mice was responding to the mouse I changed the X config to Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Buttons" "7" Option "Resolution""1000" EndSection and restarted X and at that point it started working. This is the first time I've seen the ps/2 mouse work with /dev/input/mice. This is basically the same X configuration that wasn't working when the system first installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436271: PS/2 mouse not working
Adrian Mariano wrote: > I rebooted with the mouse in the ps/2 port and tried the experiment > again. > > When I do 'cat /dev/psaux' or 'cat /dev/input/mice' and move the mouse > I see characters on the terminal in both cases. > And Xorg works with /dev/input/mice and /dev/psaux without evdev ? Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436271: PS/2 mouse not working
Adrian Mariano wrote: > When I first installed, the mouse was on the ps/2 port. The > configuration that was supplied by the installer was > > Section "InputDevice" > Identifier "Configured Mouse" > Driver "mouse" > Option "CorePointer" > Option "Device""/dev/input/mice" > Option "Protocol" "ImPS/2" > Option "Emulate3Buttons" "true" > EndSection > That's the default config provided by the installer. > The mouse did not work. I moved the mouse from the ps/2 port to the > USB port and it worked fine. > > Then I tried changing /dev/input/mice to /dev/psaux. The mouse WORKED > FINE with this setup. So PS/2 on /dev/psaux worked once. Then it would be a kernel problem or so. But you said earlier that pluging on PS/2 did not generate any character in "cat /dev/psaux" or "cat /dev/input/mice". This needs to be clarified. Either /dev/psaux works (and generates characters) or it doesn't at all. > Is it possible that some action (e.g. reboot) is necessary to cause > the kernel to realize there is a mouse on the ps/2 port? > I don't think so. Please check your BIOS in case there some config for the PS/2 port. And check whether PS/2 works in other Linux/OS if you can. Brice -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436271: PS/2 mouse not working
On Wed, Aug 08, 2007 at 07:31:14AM +0200, Brice Goglin wrote: > Adrian Mariano wrote: > > I have never observed /dev/input/mice to work when the mouse was > > plugged into the PS/2 port. At the moment I am using evdev and have > > the mouse plugged into the USB and the mouse works. If I switch it to > > the PS/2 it doesn't work. > > > > After switching the mouse to the PS/2 I tried "cat /dev/input/mice" > > and saw nothing. I also tried "cat /dev/psaux" and also saw nothing. > > (Is some action required for the PS/2 port to realize it's got a mouse > > connected?) > > > > Just as a confirmation I put the mouse back in the USB and did "cat > > /dev/input/mice" and when I moved the mouse I got characters. > > > > Then the bug is not in X. If psmouse is loaded and events don't appear > in /dev/psaux or /dev/input/mice, something is missing in the kernel or > so. Did the ps/2 mouse ever work before installing this Debian? In > another Linux? In Windows? Any BIOS option to enable it? I rebooted with the mouse in the ps/2 port and tried the experiment again. When I do 'cat /dev/psaux' or 'cat /dev/input/mice' and move the mouse I see characters on the terminal in both cases. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#436271: PS/2 mouse not working
On Wed, Aug 08, 2007 at 07:31:14AM +0200, Brice Goglin wrote: > Adrian Mariano wrote: > > I have never observed /dev/input/mice to work when the mouse was > > plugged into the PS/2 port. At the moment I am using evdev and have > > the mouse plugged into the USB and the mouse works. If I switch it to > > the PS/2 it doesn't work. > > > > After switching the mouse to the PS/2 I tried "cat /dev/input/mice" > > and saw nothing. I also tried "cat /dev/psaux" and also saw nothing. > > (Is some action required for the PS/2 port to realize it's got a mouse > > connected?) > > > > Just as a confirmation I put the mouse back in the USB and did "cat > > /dev/input/mice" and when I moved the mouse I got characters. > > > > Then the bug is not in X. If psmouse is loaded and events don't appear > in /dev/psaux or /dev/input/mice, something is missing in the kernel or > so. Did the ps/2 mouse ever work before installing this Debian? In > another Linux? In Windows? Any BIOS option to enable it? When I first installed, the mouse was on the ps/2 port. The configuration that was supplied by the installer was Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" EndSection The mouse did not work. I moved the mouse from the ps/2 port to the USB port and it worked fine. Then I tried changing /dev/input/mice to /dev/psaux. The mouse WORKED FINE with this setup. (It worked just as well as it worked on the USB or as it now works with evdev on the USB---everything worked but the tilting of the tilt wheel.) This seems puzzling in light of the recent behavior with /dev/psaux. Is it possible that some action (e.g. reboot) is necessary to cause the kernel to realize there is a mouse on the ps/2 port? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
