Bug#982299: Re. RTSP streams are not displayed with version 3.0.12 on Debian Sid
Oh, that is a bad news. :( Would you please tell me if you have any plan to rewrite some code to play RTSP stream again? It is a very fine function. Best regards, Gulfstream
Bug#982368: Re: Bug#982368: VLC can not play rtsp stream after upgraded to 3.0.12-2
Oh, that is a bad news. :( Would you please tell me if you have any plan to rewrite some code to play RTSP stream again? It is a very fine function. Best regards, Gulfstream > -原始邮件- > 发件人: "Sebastian Ramacher" > 发送时间: 2021-02-09 21:29:00 (星期二) > 收件人: gulfstream , 982...@bugs.debian.org > 抄送: > 主题: Re: Bug#982368: VLC can not play rtsp stream after upgraded to 3.0.12-2 > > Control: forcemerge 982299 -1 > > On 2021-02-09 21:17:34, gulfstream wrote: > > Package: vlc > > Version: 3.0.12-2 > > Severity: important > > > > > > I have pgraded the VLC to 3.0.12-2, and found that the RTSP stream could > > not be play with the message "[7fe1c0001680] satip stream error: Failed > > to setup RTSP session". > > > > It worked fine before the upgrading yesterday. > > See #982299 > > Cheers > > > > > > > > > Best regards, > > Gulfstream > > > > > > > > > > -- System Information: > > Debian Release: bullseye/sid > > APT prefers testing > > APT policy: (500, 'testing') > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.10.0-3-amd64 (SMP w/12 CPU threads) > > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > > Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE > > not set > > Shell: /bin/sh linked to /usr/bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > Versions of packages vlc depends on: > > ii vlc-bin 3.0.12-2 > > ii vlc-plugin-base 3.0.12-2 > > ii vlc-plugin-qt3.0.12-2 > > ii vlc-plugin-video-output 3.0.12-2 > > > > Versions of packages vlc recommends: > > ii vlc-l10n 3.0.12-2 > > ii vlc-plugin-access-extra3.0.12-2 > > ii vlc-plugin-notify 3.0.12-2 > > ii vlc-plugin-samba 3.0.12-2 > > ii vlc-plugin-skins2 3.0.12-2 > > ii vlc-plugin-video-splitter 3.0.12-2 > > ii vlc-plugin-visualization 3.0.12-2 > > > > Versions of packages vlc suggests: > > pn vlc-plugin-fluidsynth > > pn vlc-plugin-jack > > pn vlc-plugin-svg > > > > Versions of packages libvlc-bin depends on: > > ii libc62.31-9 > > ii libvlc5 3.0.12-2 > > > > Versions of packages libvlc5 depends on: > > ii libc62.31-9 > > ii libvlccore9 3.0.12-2 > > > > Versions of packages libvlc5 recommends: > > ii libvlc-bin 3.0.12-2 > > > > Versions of packages vlc-bin depends on: > > ii libc6 2.31-9 > > ii libvlc-bin 3.0.12-2 > > ii libvlc5 3.0.12-2 > > > > Versions of packages vlc-plugin-access-extra depends on: > > ii libc62.31-9 > > ii libvlccore9 [vlc-plugin-abi-3-0-0f] 3.0.12-2 > > ii libvncclient10.9.13+dfsg-1 > > ii libxcb-composite01.14-3 > > ii libxcb-shm0 1.14-3 > > ii libxcb1 1.14-3 > > > > Versions of packages vlc-plugin-base depends on: > > ii liba52-0.7.4 0.7.4-20 > > ii libarchive13 3.4.3-2 > > ii libaribb24-0 1.0.3-2 > > ii libasound2 1.2.4-1.1 > > ii libass9 1:0.15.0-1 > > ii libavahi-client3 0.8-3 > > ii libavahi-common3 0.8-3 > > ii libavc1394-0 0.5.4-5 > > ii libavcodec58 7:4.3.1-8 > > ii libavformat587:4.3.1-8 > > ii libavutil56 7:4.3.1-8 > > ii libbluray2 1:1.2.1-4 > > ii libc62.31-9 > > ii libcairo21.16.0-5 > > ii libcddb2 1.3.2-6+b1 > > ii libchromaprint1 1.5.0-2 > > ii libdav1d40.7.1-3 > > ii libdbus-1-3 1.12.20-1 > > ii libdc1394-25 2.2.6-3 > > ii libdca0 0.0.7-2 > > ii libdvbpsi10 1.3.3-1 > > ii libdvdnav4 6.1.0-1+b1 > > ii libdvdread8 6.1.1-2 > > ii libebml5 1.4.1-1 > > ii libfaad2 2.10.0-1 > > ii libflac8 1.3.3-2 > > ii libfontconfig1 2.13.1-4.2 > > ii libfreetype6 2.10.4+dfsg-1 > > ii libfribidi0 1.0.8-2 > > ii libgcc-s110.2.1-6 > > ii libgcrypt20 1.8.7-2 > > ii libglib2.0-0 2.66.6-1 > > ii libgnutls30 3.7.0-5 > > ii libgpg-error01.38-2 > > ii libharfbuzz0b2.7.4-1 > > ii libixml101:1.8.4-2 > > ii libjpeg62-turbo 1:2.0.5-2 > > ii libkate1
Bug#964849: Re: 回复：Bug#964849: "Invalid data found when processing input" got when using ffmpeg
Thanks for your suggest. I got the reason which another software was installed with another ffmpeg, and set PATH point to it. Now I solved it. Thank you again! Best regards, Gulfstream > -原始邮件- > 发件人: "Jonas Smedegaard" > 发送时间: 2020-07-11 15:11:54 (星期六) > 收件人: 964...@bugs.debian.org, "王钢林" > 抄送: > 主题: Re: 回复：Bug#964849: "Invalid data found when processing input" got when > using ffmpeg > > Quoting 王钢林 (2020-07-11 09:01:33) > > I am glad to receive your reply. But the ffmpeg was installed from debian > > source by apt-get without any other ffmpeg version was installed. > > Please provide the output of each of these commands: > > echo $PATH > > which ffmpeg > > ffmpeg > > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#958304: Can not make Epson L1800 work
Hello, the epson-inkjet-printer-201312w need LSB which is abandoned by Debian. So it is not be used in Debian 10. Would you please tell me how to use the epson-inkjet-printer-201312w in Debian without LSB? Thank you very much! Best regards, Gulfstream
Bug#954203: Re: Bug#954203: Client splash and exit after login in
Thanks for your reply! My next question is How to connect the xrdp server using remmina client? I don't find where to set the glyph cache. And When will the bug be resolve? Thank again! Best regards, Gulfstream > -原始邮件- > 发件人: "Bernhard Übelacker" > 发送时间: 2020-03-21 19:07:38 (星期六) > 收件人: 954...@bugs.debian.org, gulfstream > 抄送: > 主题: Re: Bug#954203: Client splash and exit after login in > > Hello, > this seems to be caused by xrdp using glyph cache even > when the client does not advertise it. > Additionally freerdp does now stricter checks. > > Upstream bugs are here [1]. > > A workaround could be to use xfreerdp like this: > > xfreerdp +glyph-cache /relax-order-checks /v:hostname > > Kind regards, > Bernhard > > > [1] > https://github.com/neutrinolabs/xrdp/issues/1266 > > https://gitlab.com/Remmina/Remmina/issues/1770 > > https://github.com/FreeRDP/FreeRDP/issues/5072 > https://github.com/FreeRDP/FreeRDP/issues/5207
Bug#954158: Re: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome
I looked through the folder /usr/bin just now, and found the xrdp is also in the folder /usr/bin # ls xr* xrandr xrdb xrdp-dis xrdp-genkeymap xrdp-keygen xrdp-sesadmin xrdp-sesrun xrefresh So the message in the vnc log fle is so strange. > -原始邮件- > 发件人: "Ola Lundqvist" > 发送时间: 2020-03-18 20:35:00 (星期三) > 收件人: gulfstream > 抄送: "Ola Lundqvist" , 954...@bugs.debian.org > 主题: Re: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output > a blank screen with gray color under gnome > > Hi > > Yes root does not help because the search path is not including > /usr/sbin for vnc. > /usr/sbin and /sbin is only intended for system commands that root run > for system maintenance and for system services. > This is why I do not understand why xrdb has moved its location. The > intention of this tool is for the user to run. > > In your case you can edit your startup file manually to include the > path directly. > > Best regards > > // Ola > > On Wed, 18 Mar 2020 at 13:24, wrote: > > > > But when I start vnc with root, the smae log is also got: > > > > 18/03/20 20:21:01 Xvnc version TightVNC-1.3.9 > > 18/03/20 20:21:01 Copyright (C) 2000-2007 TightVNC Group > > 18/03/20 20:21:01 Copyright (C) 1999 AT&T Laboratories Cambridge > > 18/03/20 20:21:01 All Rights Reserved. > > 18/03/20 20:21:01 See http://www.tightvnc.com/ for information on TightVNC > > 18/03/20 20:21:01 Desktop name 'X' (athena:2) > > 18/03/20 20:21:01 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t > > 18/03/20 20:21:01 Listening for VNC connections on TCP port 5902 > > xrdb: No such file or directory > > xrdb: can't open file '/root/.Xresources' > > Terminated > > > > 18/03/20 20:21:24 Got connection from client 127.0.0.1 > > 18/03/20 20:21:24 Using protocol version 3.8 > > 18/03/20 20:21:24 Enabling TightVNC protocol extensions > > 18/03/20 20:21:27 Full-control authentication passed by 127.0.0.1 > > 18/03/20 20:21:27 Pixel format for client 127.0.0.1: > > 18/03/20 20:21:27 32 bpp, depth 24, little endian > > 18/03/20 20:21:27 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 > > 18/03/20 20:21:27 no translation needed > > 18/03/20 20:21:27 Using raw encoding for client 127.0.0.1 > > 18/03/20 20:21:27 Using compression level 1 for client 127.0.0.1 > > 18/03/20 20:21:27 Using image quality level 6 for client 127.0.0.1 > > 18/03/20 20:21:27 Enabling X-style cursor updates for client 127.0.0.1 > > 18/03/20 20:21:27 Enabling cursor position updates for client 127.0.0.1 > > 18/03/20 20:21:27 Enabling LastRect protocol extension for client 127.0.0.1 > > > > > > And the same blank screen was got in the client. > > > > > > > > -原始邮件- > > 发件人:"Ola Lundqvist" > > 发送时间:2020-03-18 19:55:05 (星期三) > > 收件人: gulfstream , 954...@bugs.debian.org > > 抄送: "Ola Lundqvist" > > 主题: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a > > blank screen with gray color under gnome > > > > Hi > > > > Then I understand. It must have changed path from /usr/bin to /usr/sbin > > > > I do not really understand why. It is not only for root to run... > > > > // Ola > > > > On Wed, 18 Mar 2020 at 11:39, wrote: > >> > >> I installed xrdp with apt-get, so its path is default of debian. > >> > >> $ whereis xrdp > >> xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp > >> /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz > >> > >> > >> -原始邮件- > >> 发件人:"Ola Lundqvist" > >> 发送时间:2020-03-18 16:29:28 (星期三) > >> 收件人: wg...@china.com, 954...@bugs.debian.org > >> 抄送: > >> 主题: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen > >> with gray color under gnome > >> > >> What is the path of xrdb on your installation? > >> > >> // Ola > >> > >> On Wed, 18 Mar 2020 at 06:57, wrote: > >>> > >>> Hi, I am glad to receive your reply. I have checked the xstartup which in > >>> the folder ~/.vnc. It is created by tightvncserver automatically. It is > >>> as below, > >>> > >>> #!/bin/sh > >>> > >>> xrdb $HOME/.Xresources > >>> xsetroot -solid grey > >>> #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP > >>> Desktop" & > >>> #x-window-manager & > >>> # Fix to make GNOME work > >>> export XKL_XMODMAP_DISABLE=1 > >>> /etc/X11/Xsession > >>> > >>> > >>> And the log file is, > >>> > >>> 20 23:07:54 Xvnc version TightVNC-1.3.9 > >>> 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group > >>> 17/03/20 23:07:54 Copyright (C) 1999 AT&T Laboratories Cambridge > >>> 17/03/20 23:07:54 All Rights Reserved. > >>> 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC > >>> 17/03/20 23:07:54 Desktop name 'X' (athena:1) > >>> 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t > >>> 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901 > >>> xrdb: No such file or directory > >>> xrdb: can't open file '/home/wgl/.Xresources' > >>> > >>> 17/03/20 23:08:29 Got connection from client 127.0.0.1 > >>> 17/03/20 23:08:29 Using proto
Bug#954158: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome
But when I start vnc with root, the smae log is also got: 18/03/20 20:21:01 Xvnc version TightVNC-1.3.9 18/03/20 20:21:01 Copyright (C) 2000-2007 TightVNC Group 18/03/20 20:21:01 Copyright (C) 1999 AT&T Laboratories Cambridge 18/03/20 20:21:01 All Rights Reserved. 18/03/20 20:21:01 See http://www.tightvnc.com/ for information on TightVNC 18/03/20 20:21:01 Desktop name 'X' (athena:2) 18/03/20 20:21:01 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t 18/03/20 20:21:01 Listening for VNC connections on TCP port 5902 xrdb: No such file or directory xrdb: can't open file '/root/.Xresources' Terminated 18/03/20 20:21:24 Got connection from client 127.0.0.1 18/03/20 20:21:24 Using protocol version 3.8 18/03/20 20:21:24 Enabling TightVNC protocol extensions 18/03/20 20:21:27 Full-control authentication passed by 127.0.0.1 18/03/20 20:21:27 Pixel format for client 127.0.0.1: 18/03/20 20:21:27 32 bpp, depth 24, little endian 18/03/20 20:21:27 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 18/03/20 20:21:27 no translation needed 18/03/20 20:21:27 Using raw encoding for client 127.0.0.1 18/03/20 20:21:27 Using compression level 1 for client 127.0.0.1 18/03/20 20:21:27 Using image quality level 6 for client 127.0.0.1 18/03/20 20:21:27 Enabling X-style cursor updates for client 127.0.0.1 18/03/20 20:21:27 Enabling cursor position updates for client 127.0.0.1 18/03/20 20:21:27 Enabling LastRect protocol extension for client 127.0.0.1 And the same blank screen was got in the client. -原始邮件- 发件人:"Ola Lundqvist" 发送时间:2020-03-18 19:55:05 (星期三) 收件人: gulfstream , 954...@bugs.debian.org 抄送: "Ola Lundqvist" 主题: Re: Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome Hi Then I understand. It must have changed path from /usr/bin to /usr/sbin I do not really understand why. It is not only for root to run... // Ola On Wed, 18 Mar 2020 at 11:39, wrote: I installed xrdp with apt-get, so its path is default of debian. $ whereis xrdp xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz -原始邮件- 发件人:"Ola Lundqvist" 发送时间:2020-03-18 16:29:28 (星期三) 收件人:wg...@china.com, 954...@bugs.debian.org 抄送: 主题: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome What is the path of xrdb on your installation? // Ola On Wed, 18 Mar 2020 at 06:57, wrote: Hi, I am glad to receive your reply. I have checked the xstartup which in the folder ~/.vnc. It is created by tightvncserver automatically. It is as below, #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & #x-window-manager & # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession And the log file is, 20 23:07:54 Xvnc version TightVNC-1.3.9 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group 17/03/20 23:07:54 Copyright (C) 1999 AT&T Laboratories Cambridge 17/03/20 23:07:54 All Rights Reserved. 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC 17/03/20 23:07:54 Desktop name 'X' (athena:1) 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901 xrdb: No such file or directory xrdb: can't open file '/home/wgl/.Xresources' 17/03/20 23:08:29 Got connection from client 127.0.0.1 17/03/20 23:08:29 Using protocol version 3.8 17/03/20 23:08:29 Enabling TightVNC protocol extensions 17/03/20 23:08:32 Full-control authentication passed by 127.0.0.1 17/03/20 23:08:32 Pixel format for client 127.0.0.1: 17/03/20 23:08:32 32 bpp, depth 24, little endian 17/03/20 23:08:32 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 17/03/20 23:08:32 no translation needed 17/03/20 23:08:32 Using raw encoding for client 127.0.0.1 17/03/20 23:08:32 Using compression level 1 for client 127.0.0.1 17/03/20 23:08:32 Using image quality level 6 for client 127.0.0.1 17/03/20 23:08:32 Enabling X-style cursor updates for client 127.0.0.1 17/03/20 23:08:32 Enabling cursor position updates for client 127.0.0.1 17/03/20 23:08:32 Enabling LastRect protocol extension for client 127.0.0.1 17/03/20 23:09:23 Client 127.0.0.1 gone 17/03/20 23:09:23 Statistics: 17/03/20 23:09:23 key events received 0, pointer events 34 17/03/20 23:09:23 framebuffer updates 1, rectangles 3, bytes 3145834 17/03/20 23:09:23 cursor shape updates 1, bytes 82 17/03/20 23:09:23 cursor position updates 1, bytes 12 17/03/20 23:09:23 raw rectangles 1, bytes 3145740 17/03/20 23:09:23 raw bytes equivalent 3145740, compression ratio 1.00 There is a message "xrdb: No such file or directory" in the log, but the xrdb was installed in the computer. I don't know if it is a bug of tightvnc or a mistake configuration of xstratup. Btw, I test the tightvncserv
Bug#954158: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome
I installed xrdp with apt-get, so its path is default of debian. $ whereis xrdp xrdp: /usr/sbin/xrdp /usr/lib/x86_64-linux-gnu/xrdp /etc/xrdp /usr/share/xrdp /usr/share/man/man8/xrdp.8.gz -原始邮件- 发件人:"Ola Lundqvist" 发送时间:2020-03-18 16:29:28 (星期三) 收件人: wg...@china.com, 954...@bugs.debian.org 抄送: 主题: Re: Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome What is the path of xrdb on your installation? // Ola On Wed, 18 Mar 2020 at 06:57, wrote: Hi, I am glad to receive your reply. I have checked the xstartup which in the folder ~/.vnc. It is created by tightvncserver automatically. It is as below, #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & #x-window-manager & # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession And the log file is, 20 23:07:54 Xvnc version TightVNC-1.3.9 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group 17/03/20 23:07:54 Copyright (C) 1999 AT&T Laboratories Cambridge 17/03/20 23:07:54 All Rights Reserved. 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC 17/03/20 23:07:54 Desktop name 'X' (athena:1) 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901 xrdb: No such file or directory xrdb: can't open file '/home/wgl/.Xresources' 17/03/20 23:08:29 Got connection from client 127.0.0.1 17/03/20 23:08:29 Using protocol version 3.8 17/03/20 23:08:29 Enabling TightVNC protocol extensions 17/03/20 23:08:32 Full-control authentication passed by 127.0.0.1 17/03/20 23:08:32 Pixel format for client 127.0.0.1: 17/03/20 23:08:32 32 bpp, depth 24, little endian 17/03/20 23:08:32 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 17/03/20 23:08:32 no translation needed 17/03/20 23:08:32 Using raw encoding for client 127.0.0.1 17/03/20 23:08:32 Using compression level 1 for client 127.0.0.1 17/03/20 23:08:32 Using image quality level 6 for client 127.0.0.1 17/03/20 23:08:32 Enabling X-style cursor updates for client 127.0.0.1 17/03/20 23:08:32 Enabling cursor position updates for client 127.0.0.1 17/03/20 23:08:32 Enabling LastRect protocol extension for client 127.0.0.1 17/03/20 23:09:23 Client 127.0.0.1 gone 17/03/20 23:09:23 Statistics: 17/03/20 23:09:23 key events received 0, pointer events 34 17/03/20 23:09:23 framebuffer updates 1, rectangles 3, bytes 3145834 17/03/20 23:09:23 cursor shape updates 1, bytes 82 17/03/20 23:09:23 cursor position updates 1, bytes 12 17/03/20 23:09:23 raw rectangles 1, bytes 3145740 17/03/20 23:09:23 raw bytes equivalent 3145740, compression ratio 1.00 There is a message "xrdb: No such file or directory" in the log, but the xrdb was installed in the computer. I don't know if it is a bug of tightvnc or a mistake configuration of xstratup. Btw, I test the tightvncserver in Debian Buster, and same result was got. Best regards, Gulfstream -原始邮件- 发件人:"Ola Lundqvist" 发送时间:2020-03-18 04:31:44 (星期三) 收件人: gulfstream , 954...@bugs.debian.org 抄送:cont...@bugs.debian.org 主题: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome tags 954158 + moreinfo severity 954158 minor thanks Hi Have you checked your vnc startup script in ~/.vnc/xstartup or alternatively the startup script in ~/.vncstartup This is the set of commands used to start the window manager and other stuff. When reading the manual I can see that this is not really clear. This could be improved. // Ola On Tue, 17 Mar 2020 at 16:33, gulfstream wrote: Package: tightvncserver Version: 1:1.3.9-9.1 Severity: grave Hello, I want to use tightvnc under the gnome desktop, but only a blank screen was got in the client. Nothing is on the screen except a cursor. What is the matter? Would you please resolve it? Thank you very much! Best regards, Gulfstream -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tightvncserver depends on: ii libc62.29-10 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libx11-6 2:1.6.9-2 ii perl 5.30.0-9 ii x11-common 1:7.7+20 ii x11-utils7.7+5 ii xauth1:1.0.10-1 ii xserver-common 2:1.20.7-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tightvncserver recommends: ii x11-xserver-utils 7.7+8 ii xfonts-base1:1.0.5 Versions of packages tightvncserver suggests: pn tightvnc-java
Bug#954158: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome
Hi, I am glad to receive your reply. I have checked the xstartup which in the folder ~/.vnc. It is created by tightvncserver automatically. It is as below, #!/bin/sh xrdb $HOME/.Xresources xsetroot -solid grey #x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" & #x-window-manager & # Fix to make GNOME work export XKL_XMODMAP_DISABLE=1 /etc/X11/Xsession And the log file is, 20 23:07:54 Xvnc version TightVNC-1.3.9 17/03/20 23:07:54 Copyright (C) 2000-2007 TightVNC Group 17/03/20 23:07:54 Copyright (C) 1999 AT&T Laboratories Cambridge 17/03/20 23:07:54 All Rights Reserved. 17/03/20 23:07:54 See http://www.tightvnc.com/ for information on TightVNC 17/03/20 23:07:54 Desktop name 'X' (athena:1) 17/03/20 23:07:54 Protocol versions supported: 3.3, 3.7, 3.8, 3.7t, 3.8t 17/03/20 23:07:54 Listening for VNC connections on TCP port 5901 xrdb: No such file or directory xrdb: can't open file '/home/wgl/.Xresources' 17/03/20 23:08:29 Got connection from client 127.0.0.1 17/03/20 23:08:29 Using protocol version 3.8 17/03/20 23:08:29 Enabling TightVNC protocol extensions 17/03/20 23:08:32 Full-control authentication passed by 127.0.0.1 17/03/20 23:08:32 Pixel format for client 127.0.0.1: 17/03/20 23:08:32 32 bpp, depth 24, little endian 17/03/20 23:08:32 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 17/03/20 23:08:32 no translation needed 17/03/20 23:08:32 Using raw encoding for client 127.0.0.1 17/03/20 23:08:32 Using compression level 1 for client 127.0.0.1 17/03/20 23:08:32 Using image quality level 6 for client 127.0.0.1 17/03/20 23:08:32 Enabling X-style cursor updates for client 127.0.0.1 17/03/20 23:08:32 Enabling cursor position updates for client 127.0.0.1 17/03/20 23:08:32 Enabling LastRect protocol extension for client 127.0.0.1 17/03/20 23:09:23 Client 127.0.0.1 gone 17/03/20 23:09:23 Statistics: 17/03/20 23:09:23 key events received 0, pointer events 34 17/03/20 23:09:23 framebuffer updates 1, rectangles 3, bytes 3145834 17/03/20 23:09:23 cursor shape updates 1, bytes 82 17/03/20 23:09:23 cursor position updates 1, bytes 12 17/03/20 23:09:23 raw rectangles 1, bytes 3145740 17/03/20 23:09:23 raw bytes equivalent 3145740, compression ratio 1.00 There is a message "xrdb: No such file or directory" in the log, but the xrdb was installed in the computer. I don't know if it is a bug of tightvnc or a mistake configuration of xstratup. Btw, I test the tightvncserver in Debian Buster, and same result was got. Best regards, Gulfstream -原始邮件- 发件人:"Ola Lundqvist" 发送时间:2020-03-18 04:31:44 (星期三) 收件人: gulfstream , 954...@bugs.debian.org 抄送: cont...@bugs.debian.org 主题: Re: Bug#954158: tightvncserver output a blank screen with gray color under gnome tags 954158 + moreinfo severity 954158 minor thanks Hi Have you checked your vnc startup script in ~/.vnc/xstartup or alternatively the startup script in ~/.vncstartup This is the set of commands used to start the window manager and other stuff. When reading the manual I can see that this is not really clear. This could be improved. // Ola On Tue, 17 Mar 2020 at 16:33, gulfstream wrote: Package: tightvncserver Version: 1:1.3.9-9.1 Severity: grave Hello, I want to use tightvnc under the gnome desktop, but only a blank screen was got in the client. Nothing is on the screen except a cursor. What is the matter? Would you please resolve it? Thank you very much! Best regards, Gulfstream -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), LANGUAGE=zh_CN.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tightvncserver depends on: ii libc62.29-10 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libx11-6 2:1.6.9-2 ii perl 5.30.0-9 ii x11-common 1:7.7+20 ii x11-utils7.7+5 ii xauth1:1.0.10-1 ii xserver-common 2:1.20.7-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages tightvncserver recommends: ii x11-xserver-utils 7.7+8 ii xfonts-base1:1.0.5 Versions of packages tightvncserver suggests: pn tightvnc-java -- no debconf information -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.como...@debian.org| | http://inguza.com/Mobile: +46 (0)70-332 1551 | ---
Bug#925944: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot
Hi, I found that the gnome-shell extension can not show the status of laptop cell charging. So I reinstalled the laptop-mode-tools, and changed the wired interface name from "eth0" to "enp0s31f6" in the file /etc/laptop-mode/conf.d/ethernet.conf as advice from Ritesh. Then, I reboot several times, it seems running OK. I will try more times. > -原始邮件- > 发件人: "Ritesh Raj Sarraf" > 发送时间: 2020-02-27 01:56:04 (星期四) > 收件人: wg...@china.com, 952...@bugs.debian.org > 抄送: 925...@bugs.debian.org > 主题: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name > maybe changed when reboot > > Control: serverity -1 important > > > I am lowering the severity as this is common reflection of problems > elsewhere disguising as a problem with laptop-mode-tools. > > > Couple of things to mention: > > * If you know of the persistent name for your interface, can you > populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if > that helps > > * From the logs that you've shared on the bug report, I'm lost. That > log is huge. laptop-mode-tools will apply power savings to ethernet > device. On boot, this happens quite early on. And probably that is > causing the problem. But I'd still like to see what holds the device so > long that NetworkManager fails to rename it. Does disabling the > `ethernet` module in laptop-mode-tools solve your problem ? If so, as a > workaround you can start with disabling it. And then try to investigate > what may be causing the device to remain busy for so long. > > * There's a valid bug report #925944, where a side-effect of enabling > power savings on the ethernet device results in NetworkManager not > considering the device. I am not sure how that should be solved because > how other tools (like NetworkManager, avahi etc) behave is beyond the > scope. But, if the integration of these tools do not work proper, > disabling one of the tools (like laptop-mode-tools) or a particular > hardware power savings (like ethernet module), could be a viable > option. > > > Coming up with an ideal default is challenging and I struggle to find a > balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is > documented in the manpage. > > > For the case of #925944, I think we should remove eth0 from the default > list. Because most devices these days have a unique persistent name and > it is best left to the user to find out the name and populate it in the > configuration file. That is what my upload today, 1.73.1-2 does. > > > On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote: > > OK, thank you very much! I will wait for all things are fine again! > > Thank you again! > > > > > > > > > -原始邮件- > > > 发件人: "Michael Biebl" > > > 发送时间: 2020-02-26 23:09:22 (星期三) > > > 收件人: wg...@china.com, 952...@bugs.debian.org, > > > laptop-mode-to...@packages.debian.org > > > 抄送: > > > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe > > > changed when reboot > > > > > > Control: reassign -1 laptop-mode-tools > > > Control: retitle -1 lmt breaks network interface renaming > > > Control: severity -1 serious > > > > > > Am 26.02.20 um 16:01 schrieb wg...@china.com: > > > > As your recommendation, I removed the laptop-mode-tools, it seems > > > > that wired interface' name is correct for several boot. But if > > > > there is no laptop-mode-tools, how I using its function for > > > > saving power to laptop? > > > > > > Don't use laptop-mode-tools. The kernel does it sufficiently well > > > on > > > it's own these days. I'm not actually sure what business > > > laptop-mode-tools has with your network interfaces. > > > > > > I'm going to reassign this bug report to laptop-mode-tools and > > > bumping > > > the severity to RC. > > > > > > Michael > > > > > > > > > > > > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System
Bug#952506: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot
> -原始邮件- > 发件人: "Ritesh Raj Sarraf" > 发送时间: 2020-02-27 01:56:04 (星期四) > 收件人: wg...@china.com, 952...@bugs.debian.org > 抄送: 925...@bugs.debian.org > 主题: Re: Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name > maybe changed when reboot > > Control: serverity -1 important > > > I am lowering the severity as this is common reflection of problems > elsewhere disguising as a problem with laptop-mode-tools. > > > Couple of things to mention: > > * If you know of the persistent name for your interface, can you > populate that into the /etc/laptop-mode/conf.d/ethernet.conf and see if > that helps I think it is not useful because that the first name of wired interface is eth0, and systemd change it to enpXXX soon. So laptop may set the interface by eth0 or enpXXX. > > * From the logs that you've shared on the bug report, I'm lost. That > log is huge. laptop-mode-tools will apply power savings to ethernet > device. On boot, this happens quite early on. And probably that is > causing the problem. But I'd still like to see what holds the device so > long that NetworkManager fails to rename it. Does disabling the > `ethernet` module in laptop-mode-tools solve your problem ? If so, as a > workaround you can start with disabling it. And then try to investigate > what may be causing the device to remain busy for so long. > > * There's a valid bug report #925944, where a side-effect of enabling > power savings on the ethernet device results in NetworkManager not > considering the device. I am not sure how that should be solved because > how other tools (like NetworkManager, avahi etc) behave is beyond the > scope. But, if the integration of these tools do not work proper, > disabling one of the tools (like laptop-mode-tools) or a particular > hardware power savings (like ethernet module), could be a viable > option. > > > Coming up with an ideal default is challenging and I struggle to find a > balance. We do have /etc/laptop-mode/conf.d/board-specific/ . It is > documented in the manpage. > > > For the case of #925944, I think we should remove eth0 from the default > list. Because most devices these days have a unique persistent name and > it is best left to the user to find out the name and populate it in the > configuration file. That is what my upload today, 1.73.1-2 does. > > > On Wed, 2020-02-26 at 23:32 +0800, wg...@china.com wrote: > > OK, thank you very much! I will wait for all things are fine again! > > Thank you again! > > > > > > > > > -原始邮件- > > > 发件人: "Michael Biebl" > > > 发送时间: 2020-02-26 23:09:22 (星期三) > > > 收件人: wg...@china.com, 952...@bugs.debian.org, > > > laptop-mode-to...@packages.debian.org > > > 抄送: > > > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe > > > changed when reboot > > > > > > Control: reassign -1 laptop-mode-tools > > > Control: retitle -1 lmt breaks network interface renaming > > > Control: severity -1 serious > > > > > > Am 26.02.20 um 16:01 schrieb wg...@china.com: > > > > As your recommendation, I removed the laptop-mode-tools, it seems > > > > that wired interface' name is correct for several boot. But if > > > > there is no laptop-mode-tools, how I using its function for > > > > saving power to laptop? > > > > > > Don't use laptop-mode-tools. The kernel does it sufficiently well > > > on > > > it's own these days. I'm not actually sure what business > > > laptop-mode-tools has with your network interfaces. > > > > > > I'm going to reassign this bug report to laptop-mode-tools and > > > bumping > > > the severity to RC. > > > > > > Michael > > > > > > > > > > > > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System
Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot
OK, thank you very much! I will wait for all things are fine again! Thank you again! > -原始邮件- > 发件人: "Michael Biebl" > 发送时间: 2020-02-26 23:09:22 (星期三) > 收件人: wg...@china.com, 952...@bugs.debian.org, > laptop-mode-to...@packages.debian.org > 抄送: > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when > reboot > > Control: reassign -1 laptop-mode-tools > Control: retitle -1 lmt breaks network interface renaming > Control: severity -1 serious > > Am 26.02.20 um 16:01 schrieb wg...@china.com: > > As your recommendation, I removed the laptop-mode-tools, it seems that > > wired interface' name is correct for several boot. But if there is no > > laptop-mode-tools, how I using its function for saving power to laptop? > > Don't use laptop-mode-tools. The kernel does it sufficiently well on > it's own these days. I'm not actually sure what business > laptop-mode-tools has with your network interfaces. > > I'm going to reassign this bug report to laptop-mode-tools and bumping > the severity to RC. > > Michael > > > >
Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot
As your recommendation, I removed the laptop-mode-tools, it seems that wired interface' name is correct for several boot. But if there is no laptop-mode-tools, how I using its function for saving power to laptop? Thank you! > -原始邮件- > 发件人: "Michael Biebl" > 发送时间: 2020-02-26 22:22:44 (星期三) > 收件人: wg...@china.com, 952...@bugs.debian.org > 抄送: > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when > reboot > > Am 26.02.20 um 15:18 schrieb Michael Biebl: > > Am 26.02.20 um 14:40 schrieb wg...@china.com: > >> > >> The attachment file 111.txt is the ouput of command "journalctl -alb". > >> Thank you! > > > > Ok, thanks. > > Here's the relevant part of the log: > > > > 2月 26 21:34:29 athena systemd-udevd[499]: eth0: Failed to rename > > network interface 2 from 'eth0' to 'enp0s31f6': Device or resource busy > > 2月 26 21:34:29 athena systemd-udevd[499]: eth0: Failed to process > > device, ignoring: Device or resource busy > > > > So, systemd-udevd does attempt to rename the interface but something is > > trying to use the network interface before it has been renamed, which is > > why the rename fails. > > > > Now you need to find out what part of the system is using eth0 early in > > the boot process. > > Looking at the log, right before the rename happens, you have several > laptop-mode-tools calls. laptop-mode-tools does a lot of weird and > broken stuff. > My recommendation: apt purge laptop-mode-tools > and then try again. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925944 looks very much > related. > > Michael >
Bug#952506: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when reboot
Yes, I have noticed it, but I don't know what thing is using eth0 early in the boot process. This bug did not exist several days ago. > -原始邮件- > 发件人: "Michael Biebl" > 发送时间: 2020-02-26 22:18:47 (星期三) > 收件人: wg...@china.com, 952...@bugs.debian.org > 抄送: > 主题: Re: Bug#952506: Re: Bug#952506: Wired interface name maybe changed when > reboot > > Am 26.02.20 um 14:40 schrieb wg...@china.com: > > > > The attachment file 111.txt is the ouput of command "journalctl -alb". > > Thank you! > > Ok, thanks. > Here's the relevant part of the log: > > 2月 26 21:34:29 athena systemd-udevd[499]: eth0: Failed to rename > network interface 2 from 'eth0' to 'enp0s31f6': Device or resource busy > 2月 26 21:34:29 athena systemd-udevd[499]: eth0: Failed to process > device, ignoring: Device or resource busy > > So, systemd-udevd does attempt to rename the interface but something is > trying to use the network interface before it has been renamed, which is > why the rename fails. > > Now you need to find out what part of the system is using eth0 early in > the boot process. > >
Bug#952506: Wired interface name maybe changed when reboot
When the wired interface was be named enp0s31f6: udevadm info /sys/class/net/enp0s31f6 P: /devices/pci:00/:00:1f.6/net/enp0s31f6 L: 0 E: DEVPATH=/devices/pci:00/:00:1f.6/net/enp0s31f6 E: INTERFACE=enp0s31f6 E: IFINDEX=2 E: SUBSYSTEM=net E: USEC_INITIALIZED=3512520 E: ID_NET_NAMING_SCHEME=v243 E: ID_NET_NAME_MAC=enx482ae3154ae1 E: ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd. E: ID_NET_NAME_PATH=enp0s31f6 E: ID_BUS=pci E: ID_VENDOR_ID=0x8086 E: ID_MODEL_ID=0x15bb E: ID_PCI_CLASS_FROM_DATABASE=Network controller E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller E: ID_VENDOR_FROM_DATABASE=Intel Corporation E: ID_MODEL_FROM_DATABASE=Ethernet Connection (7) I219-LM E: ID_MM_CANDIDATE=1 E: ID_PATH=pci-:00:1f.6 E: ID_PATH_TAG=pci-_00_1f_6 E: ID_NET_DRIVER=e1000e E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link E: ID_NET_NAME=enp0s31f6 E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp0s31f6 /sys/subsystem/net/devices/enp0s31f6 E: TAGS=:systemd: When the wired interface was be named eth0: udevadm info /sys/class/net/eth0 P: /devices/pci:00/:00:1f.6/net/eth0 L: 0 E: DEVPATH=/devices/pci:00/:00:1f.6/net/eth0 E: INTERFACE=eth0 E: IFINDEX=2 E: SUBSYSTEM=net Best regards, Gulfstream
Bug#952506: Wired interface name maybe changed when reboot
To the wired net interface, "eth0" was named is more often than new style "enp0s31f6".
Bug#952506: Wired interface name maybe changed when reboot
btw, the wireless interface is correct, its name is always "wlp0s20f3".
Bug#952497: Wired network interface can not be managed by Network-Manager
Hi, I notice that the wired interface's name maybe be changed while rebooting. Sometimes the wired interface's name is "enp0s31f6", sometimes it is "eth0". The Network Manager can manage the wired interface if wired interface's name is "enp0s31f6". The Network Manager can not manage the wired interface if wired inteface's name is "eth0". Best regards, Gulfstream
Bug#939505: Cannot access secondary GPU - error: [XORG] (EE)
more information: After I install package xserver-xorg-input-mouse, I got another error message. If I run optirun, the error message is: $ optirun glxgears [ 502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) [ 502.952549] [ERROR]Aborting because fallback start is disabled. if I run primusrun, the error message is: $ primusrun glxgears /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Best regards, Gulfstream
Bug#939489: Cannot access secondary GPU - error: [XORG] (EE)
more information: After I install package xserver-xorg-input-mouse, I got another error message. If I run optirun, the error message is: $ optirun glxgears [ 502.952517] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) [ 502.952549] [ERROR]Aborting because fallback start is disabled. if I run primusrun, the error message is: $ primusrun glxgears /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Best regards, Gulfstream
Bug#939505: more information
When I run opengl program with optirun or primusrun, the program can not run and I got a error message as below: $ optirun freecad [ 614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0) [ 614.056596] [ERROR]Aborting because fallback start is disabled. $ primusrun freecad /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0) Best regards, Gulfstream
Bug#939489: more information
When I run opengl program with optirun or primusrun, the program can not run and I got a error message as below: $ optirun freecad [ 614.056579] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0) [ 614.056596] [ERROR]Aborting because fallback start is disabled. $ primusrun freecad /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte in input primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Failed to load module "mouse" (module does not exist, 0) Best regards, Gulfstream
Bug#930563: Re: Bug#930563: Can not start freecad
Hello Bernhard, Thanks for your reply! I have install the proprietary nvidia drivers and it runs well. The output of commands which you list as below, > ldd /usr/bin/freecad linux-vdso.so.1 (0x7ffe69ae5000) libhdf5_openmpi.so.103 => /lib/x86_64-linux-gnu/libhdf5_openmpi.so.103 (0x7f2032967000) libmpi.so.40 => /lib/x86_64-linux-gnu/libmpi.so.40 (0x7f203285e000) libmpi_cxx.so.40 => /lib/x86_64-linux-gnu/libmpi_cxx.so.40 (0x7f203284) libFreeCADGui.so => /usr/lib/freecad-python2/lib/libFreeCADGui.so (0x7f2031a96000) libFreeCADApp.so => /usr/lib/freecad-python2/lib/libFreeCADApp.so (0x7f2031744000) libFreeCADBase.so => /usr/lib/freecad-python2/lib/libFreeCADBase.so (0x7f20315ae000) libpython2.7.so.1.0 => /lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x7f203123f000) libxerces-c-3.2.so => /lib/x86_64-linux-gnu/libxerces-c-3.2.so (0x7f2030e94000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2030c76000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f2030c71000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2030c6c000) libzipios.so.0 => /lib/x86_64-linux-gnu/libzipios.so.0 (0x7f2030a3f000) libQt5Xml.so.5 => /lib/x86_64-linux-gnu/libQt5Xml.so.5 (0x7f20309fe000) libCoin.so.80c => /lib/x86_64-linux-gnu/libCoin.so.80c (0x7f2030166000) libboost_filesystem.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_filesystem.so.1.67.0 (0x7f2030148000) libboost_program_options.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_program_options.so.1.67.0 (0x7f20300c1000) libboost_regex.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_regex.so.1.67.0 (0x7f202ffac000) libboost_system.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f202ffa5000) libboost_thread.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_thread.so.1.67.0 (0x7f202ff77000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f202ff56000) libboost_chrono.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_chrono.so.1.67.0 (0x7f202ff4b000) libboost_date_time.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_date_time.so.1.67.0 (0x7f202ff37000) libboost_atomic.so.1.67.0 => /lib/x86_64-linux-gnu/libboost_atomic.so.1.67.0 (0x7f202ff32000) libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7f202fc89000) libQt5OpenGL.so.5 => /lib/x86_64-linux-gnu/libQt5OpenGL.so.5 (0x7f202fc2d000) libQt5PrintSupport.so.5 => /lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7f202fbb6000) libQt5Svg.so.5 => /lib/x86_64-linux-gnu/libQt5Svg.so.5 (0x7f202fb6) libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 (0x7f202f9bf000) libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x7f202f368000) libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 (0x7f202f361000) libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x7f202edd4000) libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 (0x7f202e8d9000) libspnav.so.0 => /lib/libspnav.so.0 (0x7f202e6d5000) libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7f202e594000) libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 => /lib/x86_64-linux-gnu/libshiboken2-python2.7.x86_64-linux-gnu.so.5.11 (0x7f202e568000) libpyside2-python2.7.x86_64-linux-gnu.so.5.11 => /lib/x86_64-linux-gnu/libpyside2-python2.7.x86_64-linux-gnu.so.5.11 (0x7f202e52e000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f202e3a8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f202e225000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f202e20b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f202e04a000) libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 (0x7f202de47000) libopen-rte.so.40 => /lib/x86_64-linux-gnu/libopen-rte.so.40 (0x7f202dd8f000) libopen-pal.so.40 => /lib/x86_64-linux-gnu/libopen-pal.so.40 (0x7f202dce) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f202dcd6000) libhwloc.so.5 => /lib/x86_64-linux-gnu/libhwloc.so.5 (0x7f202dc94000) libevent-2.1.so.6 => /lib/x86_64-linux-gnu/libevent-2.1.so.6 (0x7f202da3e000) libevent_pthreads-2.1.so.6 => /lib/x86_64-linux-gnu/libevent_pthreads-2.1.so.6 (0x7f202d83b000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f202d82) libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x7f202d792000) libicui18n.so.63 => /lib/x86_64-linux-gnu/libicui18n.so.63 (0x7f202d4b7000) libicuuc.so.63 => /lib/x86_64-linux-gnu/libicuuc.so.63 (0x7f202d2e8000) libicudata.so.63 => /lib/x86_
Bug#877519: Re: Re: Bug#877519: Re: Re: Re: Bug#877519: Bluetooth mouse suspend while using cell
Yes, this is after I added the device ID in the configuration file.
-原始邮件-
发件人:"Ritesh Raj Sarraf"
发送时间:2017-10-12 18:14:39 (星期四)
收件人: wg...@china.com
抄送: 877...@bugs.debian.org
主题: Re: Re: Bug#877519: Re: Re: Re: Bug#877519: Bluetooth mouse suspend while
using cell
Hello,
Thank you for the log. Though it is *limited* in information, I think I have
some clue from it.
On Thu, 2017-10-12 at 15:11 +0800, wg...@china.com wrote:
Oct 12 15:10:07 athena kernel: [ 572.402472] usb 1-7: new full-speed USB
device number 7 using xhci_hcd
Oct 12 15:10:08 athena kernel: [ 572.543621] usb 1-7: New USB device found,
idVendor=8087, idProduct=0a2b
Oct 12 15:10:08 athena kernel: [ 572.543631] usb 1-7: New USB device strings:
Mfr=0, Product=0, SerialNumber=0
You have device resent occuring in the kernel.
Oct 12 15:10:08 athena kernel: [ 572.545725] Bluetooth: hci0: Bootloader
revision 0.0 build 26 week 38 2015
Oct 12 15:10:08 athena kernel: [ 572.546733] Bluetooth: hci0: Device revision
is 16
Oct 12 15:10:08 athena kernel: [ 572.546742] Bluetooth: hci0: Secure boot is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546746] Bluetooth: hci0: OTP lock is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546750] Bluetooth: hci0: API lock is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546754] Bluetooth: hci0: Debug lock is
disabled
Oct 12 15:10:08 athena kernel: [ 572.546759] Bluetooth: hci0: Minimum firmware
build 1 week 10 2014
Oct 12 15:10:08 athena kernel: [ 572.547328] bluetooth hci0: firmware:
direct-loading firmware intel/ibt-12-16.sfi
Oct 12 15:10:08 athena kernel: [ 572.547339] Bluetooth: hci0: Found device
firmware: intel/ibt-12-16.sfi
Which leads to the bt stack being reinitialized.
Oct 12 15:10:08 athena gnome-shell[7272]: Allocating size to
ShellEmbeddedWindow 0x562665108ba0 without calling
gtk_widget_get_preferred_width/height(). How does the code know the size to
allocate?
Oct 12 15:10:08 athena laptop-mode: enabled, active
Oct 12 15:10:08 athena cpufreqd: cpufreqd_set_profile : Couldn't set
profile "On Demand High" set for cpu0 (390-39-ondemand)
Oct 12 15:10:08 athena cpufreqd: cpufreqd_loop: Cannot set policy,
Rule unchanged ("none").
Oct 12 15:10:08 athena root: Device /sys/bus/usb/devices/1-0:1.0 is
blacklisted, skipping auto suspend.
Oct 12 15:10:08 athena root: Device /sys/bus/usb/devices/1-7 is blacklisted,
skipping auto suspend.
Oct 12 15:10:08 athena root: Device /sys/bus/usb/devices/2-0:1.0 is
blacklisted, skipping auto suspend.
Oct 12 15:10:08 athena laptop-mode: enabled, active
Oct 12 15:10:09 athena root: Device /sys/bus/usb/devices/1-0:1.0 is
blacklisted, skipping auto suspend.
Oct 12 15:10:09 athena kernel: [ 573.919793] Bluetooth: hci0: Waiting for
firmware download to complete
Oct 12 15:10:09 athena kernel: [ 573.920670] Bluetooth: hci0: Firmware loaded
in 1344228 usecs
Oct 12 15:10:09 athena kernel: [ 573.920694] Bluetooth: hci0: Waiting for
device to boot
And then enumerated.
Oct 12 15:10:09 athena root: Device /sys/bus/usb/devices/1-7 is blacklisted,
skipping auto suspend.
Yet, all aside, this bug was about laptop-mode-tools not skipping the BT Mouse.
But in this log, it is skipping it.
Is this after you added the device ID in the configuration file, or before it
itself ?
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
Bug#877519: Re: Bug#877519: Re: Re: Re: Bug#877519: Bluetooth mouse suspend while using cell
Hi, the log information is:
Oct 12 15:10:04 athena dbus-daemon[541]: [system] Activating service
name='org.blueman.Mechanism' requested by ':1.97' (uid=4 pid=7478
comm="/usr/bin/python3 /usr/bin/blueman-applet ") (using servicehelper)
Oct 12 15:10:04 athena org.blueman.Mechanism[541]: Unable to init server: Could
not connect: Connection refused
Oct 12 15:10:04 athena org.blueman.Mechanism[541]: Unable to init server: Could
not connect: Connection refused
Oct 12 15:10:04 athena blueman-mechanism: Starting blueman-mechanism
Oct 12 15:10:04 athena dbus-daemon[541]: [system] Successfully activated
service 'org.blueman.Mechanism'
Oct 12 15:10:04 athena blueman-mechani[14490]: gtk_icon_theme_get_for_screen:
assertion 'GDK_IS_SCREEN (screen)' failed
Oct 12 15:10:04 athena blueman-mechanism: loading RfKill
Oct 12 15:10:04 athena blueman-mechanism: loading Rfcomm
Oct 12 15:10:04 athena blueman-mechanism: loading Ppp
Oct 12 15:10:04 athena blueman-mechanism: loading Network
Oct 12 15:10:04 athena systemd[1]: Starting Load/Save RF Kill Switch Status...
Oct 12 15:10:04 athena systemd[1]: Started Load/Save RF Kill Switch Status.
Oct 12 15:10:04 athena kernel: [ 569.067736] usb 1-7: USB disconnect, device
number 6
Oct 12 15:10:04 athena blueman.desktop[7478]: ERROR:dbus.connection:Exception
in handler for D-Bus signal:
Oct 12 15:10:04 athena blueman.desktop[7478]: Traceback (most recent call last):
Oct 12 15:10:04 athena blueman.desktop[7478]: File
"/usr/lib/python3/dist-packages/dbus/connection.py", line 230, in
maybe_handle_message
Oct 12 15:10:04 athena blueman.desktop[7478]: self._handler(*args, **kwargs)
Oct 12 15:10:04 athena blueman.desktop[7478]: File
"/usr/lib/python3/dist-packages/blueman/bluez/PropertiesBlueZInterface.py",
line 55, in wrapper
Oct 12 15:10:04 athena blueman.desktop[7478]: handler(name, value, **kwargs)
Oct 12 15:10:04 athena blueman.desktop[7478]: File
"/usr/lib/python3/dist-packages/blueman/plugins/applet/GameControllerWakelock.py",
line 36, in on_device_property_changed
Oct 12 15:10:04 athena blueman.desktop[7478]: klass =
Device(path).get_properties()["Class"] & 0x1fff
Oct 12 15:10:04 athena blueman.desktop[7478]: KeyError: 'Class'
Oct 12 15:10:04 athena systemd-rfkill[14493]: Failed to open device: No such
device
Oct 12 15:10:04 athena /usr/lib/gdm3/gdm-x-session[7140]: (II) config/udev:
removing device HUAWEI Mouse
Oct 12 15:10:04 athena /usr/lib/gdm3/gdm-x-session[7140]: (**) Option "fd" "69"
Oct 12 15:10:04 athena /usr/lib/gdm3/gdm-x-session[7140]: (II) event18 - (II)
HUAWEI Mouse: (II) device removed
Oct 12 15:10:04 athena /usr/lib/gdm3/gdm-x-session[7140]: (II) UnloadModule:
"libinput"
Oct 12 15:10:04 athena /usr/lib/gdm3/gdm-x-session[7140]: (II) systemd-logind:
releasing fd for 13:82
Oct 12 15:10:04 athena bluetoothd[4011]: Endpoint unregistered: sender=:1.48
path=/MediaEndpoint/A2DPSource
Oct 12 15:10:04 athena bluetoothd[4011]: Endpoint unregistered: sender=:1.48
path=/MediaEndpoint/A2DPSink
Oct 12 15:10:04 athena bluetoothd[4011]: Endpoint unregistered: sender=:1.77
path=/MediaEndpoint/A2DPSource
Oct 12 15:10:04 athena bluetoothd[4011]: Endpoint unregistered: sender=:1.77
path=/MediaEndpoint/A2DPSink
Oct 12 15:10:06 athena cpufreqd: cpufreqd_set_profile : Couldn't set
profile "On Demand High" set for cpu0 (390-39-ondemand)
Oct 12 15:10:06 athena cpufreqd: cpufreqd_loop: Cannot set policy,
Rule unchanged ("none").
Oct 12 15:10:07 athena kernel: [ 572.402472] usb 1-7: new full-speed USB
device number 7 using xhci_hcd
Oct 12 15:10:08 athena kernel: [ 572.543621] usb 1-7: New USB device found,
idVendor=8087, idProduct=0a2b
Oct 12 15:10:08 athena kernel: [ 572.543631] usb 1-7: New USB device strings:
Mfr=0, Product=0, SerialNumber=0
Oct 12 15:10:08 athena kernel: [ 572.545725] Bluetooth: hci0: Bootloader
revision 0.0 build 26 week 38 2015
Oct 12 15:10:08 athena kernel: [ 572.546733] Bluetooth: hci0: Device revision
is 16
Oct 12 15:10:08 athena kernel: [ 572.546742] Bluetooth: hci0: Secure boot is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546746] Bluetooth: hci0: OTP lock is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546750] Bluetooth: hci0: API lock is
enabled
Oct 12 15:10:08 athena kernel: [ 572.546754] Bluetooth: hci0: Debug lock is
disabled
Oct 12 15:10:08 athena kernel: [ 572.546759] Bluetooth: hci0: Minimum firmware
build 1 week 10 2014
Oct 12 15:10:08 athena kernel: [ 572.547328] bluetooth hci0: firmware:
direct-loading firmware intel/ibt-12-16.sfi
Oct 12 15:10:08 athena kernel: [ 572.547339] Bluetooth: hci0: Found device
firmware: intel/ibt-12-16.sfi
Oct 12 15:10:08 athena gnome-shell[7272]: Allocating size to
ShellEmbeddedWindow 0x562665108ba0 without calling
gtk_widget_get_preferred_width/height(). How does the code know the size to
allocate?
Oct 12 15:10:08 athena laptop-mode: enabled, active
Oct 12 15:10:08 athena cpufreqd: cpufreqd_set_profile : Couldn't set
pr
Bug#877519: Re: Re: Re: Bug#877519: Bluetooth mouse suspend while using cell
Hi, I am so sorry for reply late. My bluetooth dongle is embedded, so I can not plug/unplug it for accquire the debug information. > -原始邮件- > 发件人: "Ritesh Raj Sarraf" > 发送时间: 2017-10-06 16:24:33 (星期五) > 收件人: wg...@china.com > 抄送: 877...@bugs.debian.org > 主题: Re: Re: Re: Bug#877519: Bluetooth mouse suspend while using cell > > On Fri, 2017-10-06 at 15:07 +0800, wg...@china.com wrote: > > The device informations about bluetooth are list as below which got > > by lsusb -v. And I do not known how to get to debug information about > > laptop-mode-tools. > > You can set DEBUG=1 in /etc/laptop-mode/conf.d/runtime-pm.conf and then > restart laptop-mode-tools > > Then, you can plun/unplug your bluetooth dongle. After that, all logs > will be stored in syslog/journalctl, from which you'll need to extract > the relevant debug logs. > > HTH > > > -- > Ritesh Raj Sarraf | http://people.debian.org/~rrs > Debian - The Universal Operating System
Bug#877519: Re: Re: Bug#877519: Bluetooth mouse suspend while using cell
The device informations about bluetooth are list as below which got by lsusb -v. And I do not known how to get to debug information about laptop-mode-tools. Bus 001 Device 003: ID 8087:0a2b Intel Corp. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 224 Wireless bDeviceSubClass 1 Radio Frequency bDeviceProtocol 1 Bluetooth bMaxPacketSize064 idVendor 0x8087 Intel Corp. idProduct 0x0a2b bcdDevice0.10 iManufacturer 0 iProduct0 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 177 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0009 1x 9 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 2 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInter
Bug#877519: Re: Bug#877519: Bluetooth mouse suspend while using cell
> -原始邮件- > 发件人: "Ritesh Raj Sarraf" > 发送时间: 2017-10-02 22:36:05 (星期一) > 收件人: gulfstream , 877...@bugs.debian.org > 抄送: > 主题: Re: Bug#877519: Bluetooth mouse suspend while using cell > > Control: tag -1 +moreinfo > > Hello, > > On Mon, 2017-10-02 at 21:28 +0800, gulfstream wrote: > > I use my laptop (Thinkpad X1 Carbon 5th) with a bluetooth mouse. The > > mouse work fine while the laptop runs with AC power supply. But The > > bluetooth mouse is a trouble while the laptop runs with the embed > > cell. The mouse will suspend if it is not be used after several > > seconds. So I want use the mouse, it must reconnect to the laptop and > > spend several seconds. it is very inconvenient! > > > > I find that the reason is bluetooth power saving of laptop mode > > tools. It can be didabled in /etc/laptop-mode/conf.d/runtime-pm.conf > > by item "AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST". After disabling, the > > bluetooth mouse will not suspend while using cell. > > > > The default list of device types was extended to accommodate such > devices. > > AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="hub usbhid usb-storage" > > > So when you say a bluetooth mouse, should I assume that the mouse > connect to a bluetooth dongle, which is connected to a USB port ? > > Because, as long as it gets enumerated as a USB device, which I suspect > is what should happen here, it would be covered. Yes, the bluetooth dongle is connected to a USB port on my laptop, and I have noticed the "hub usbhid usb-storage" is list in the AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST. But the bluetooth power saving is not be disabled unless I add the device id of bluetooth in the AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST. > > > > I think that the bluetooth should not suspend because of bluetooth > > mouse. So I advise you modify the runtime-pm.conf to add the > > bluetooth device to blacklist by default for using bluetooth mouse. > > The bluetooth power saving module is disabled by default. > runtime-pm, which takes care of most devices supporting Runtime PM > (most USB devices included), should by default blacklist most common > USB type devices. > > > Can you share your runtime-pm.conf ? Yes, my runtime-pm.conf is like this, and the device id 8087:0a2b is the bluetooth device id in my laptop. # # Configuration file for Laptop Mode Tools module runtime-pm # # For more information, consult the laptop-mode.conf(8) manual page. # ### # Runtime Power Management Settings # - # #__COMMENT If you enable this setting, laptop mode tools will automatically enable #__COMMENT the Runtime Power Management feature for all devices. #__COMMENT #__COMMENT NOTE: Some devices claim they support autosuspend, but implement it in a #__COMMENT broken way. This can mean keyboards losing keypresses, or optical mice #__COMMENT turning their LED completely off. If you have a device that misbehaves, #__COMMENT add its DEVICE ID to the blacklist section below and complain to your #__COMMENT hardware / device driver contact # # Enable debug mode for this module # Set to 1 if you want to debug this module DEBUG=0 # Enable Runtime autosuspend feature? # Set to 0 to disable CONTROL_RUNTIME_AUTOSUSPEND=1 # Set this to use opt-in/whitelist instead of opt-out/blacklist for deciding # which devices should be autosuspended. # AUTOSUSPEND_USE_WHITELIST=0 means AUTOSUSPEND_*_BLACKLIST will be used. # AUTOSUSPEND_USE_WHITELIST=1 means AUTOSUSPEND_*_WHITELIST will be used. AUTOSUSPEND_USE_WHITELIST=0 # The list of Device IDs that should not use autosuspend. Use system commands or # look into sysfs to find out the IDs of your devices. # Example: AUTOSUSPEND_DEVID_BLACKLIST="046d:c025 0123:abcd" AUTOSUSPEND_RUNTIME_DEVID_BLACKLIST="8087:0a2b" # The list of device driver types that should not use autosuspend. The driver # type is given by "DRIVER=..." in a device's uevent file. # Example: AUTOSUSPEND_DEVID_BLACKLIST="usbhid usb-storage" AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="hub usbhid usb-storage" # The list of Device IDs that should use autosuspend. Use system commands or # look into sysfs to find out the IDs of your devices. # Example: AUTOSUSPEND_DEVID_WHITELIST="046d:c025 0123:abcd" AUTOSUSPEND_RUNTIME_DEVID_WHITELIST="" # The list of device driver types that should use autosuspend. The driver # type is given by "DRIVER=..." in a device's uevent file. # Example: AUTOSUSPEND_DEVTYPE_WHITELIST="usbhid usb-storage" AUTOSUSPEND_RUNTIME_DEVTYPE_WHITELIST="" # Trigger auto-suspension of the deivce under conditional circumstances # Warning: DO NOT CHANGE THESE DEFAUTLS UNLESS YOU KNOW BATT_SUSPEND_RUNTIME=1 LM_AC_SUSPEND_RUNTIME=1 NOLM_AC_SUSPEND_RUNTIME=0 # Auto-Suspend timeout in seconds # Number of seconds after which the USB devices should suspend AUTOSUSPEND_TIMEOUT=2
