Re: [SOLVED] - Re: video driver - new thread
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Jul 25, 2017 at 01:15:48PM -0600, D. R. Evans wrote: > Felix Miata wrote on 07/23/2017 08:26 PM: > > > > >> I tried this solution (for Arch; I saw some posts about Debian, but nothing > >> that seemed to be a definitive solution): > > > >> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution > > > > [material elided] > > > The cited URL has more to offer than what you reported. It shows a fallback > > to > > deprecated vtty mode control via the vga= option, thus: > > > > "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792" > > > > Right. I didn't mention that earlier for two reasons: > 1. the allowed numbers (e.g., 792) seemed like pure magic, with no > explanation of how the numbers are calculated or their precise meaning; Maybe you're looking for this: https://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers Cheers - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAll3oFQACgkQBcgs9XrR2kaxCwCeI3GzvUD6/J5an9j1RNXrQBuP UFYAnRJ6YraMYZAza/jSO9ycMslV9Z2H =xu4N -END PGP SIGNATURE-
[SOLVED] - Re: video driver - new thread
Felix Miata wrote on 07/23/2017 08:26 PM: > >> I tried this solution (for Arch; I saw some posts about Debian, but nothing >> that seemed to be a definitive solution): > >> https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution > [material elided] > The cited URL has more to offer than what you reported. It shows a fallback to > deprecated vtty mode control via the vga= option, thus: > > "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792" > Right. I didn't mention that earlier for two reasons: 1. the allowed numbers (e.g., 792) seemed like pure magic, with no explanation of how the numbers are calculated or their precise meaning; 2. as you say, it is deprecated, so I didn't want to rely on something that might go away. However, since it seemed to work for you, I tried it (with "794") and it works fine. In particular, opening :0 and :1 works properly, unlike the case when I used the GRUB_GFXMODE option. The console text is still quite a bit larger than it was when using nouveau, but it's acceptable. So I now consider the problem solved. Thank you very much for your patience. Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: video driver - new thread
On Mon, 24 Jul 2017, Greg Wooledge wrote: > On Mon, Jul 24, 2017 at 02:20:08PM +0100, Darac Marjal wrote: > > You'd need some sort of system logging daemon. Something which runs with > > the privileges necessary to write to the log file, and which can accept > > log messages from unprivileged processes, perhaps by listening on a UNIX > > socket. > > Like syslogd, you mean. Which X doesn't use. You can redirect the stdout/stderr from the xserver to a pipe, and rsyslogd can be happily configured to read from that pipe and write to the system logger. Or you can just use xconsole and the like. -- Henrique Holschuh
Re: video driver - new thread
On Mon, Jul 24, 2017 at 02:20:08PM +0100, Darac Marjal wrote: > You'd need some sort of system logging daemon. Something which runs with > the privileges necessary to write to the log file, and which can accept > log messages from unprivileged processes, perhaps by listening on a UNIX > socket. Like syslogd, you mean. Which X doesn't use.
Re: video driver - new thread
On Mon, Jul 24, 2017 at 08:59:56AM -0400, Greg Wooledge wrote: On Sat, Jul 22, 2017 at 04:27:42PM -0400, Felix Miata wrote: I don't often here fail to find a current /var/log/Xorg.0.log. I think what's happening is the one in .local/share/ is getting copied to /var/log/ so that it remains available in the location people historically expect, where Googling will suggest to look, plus the typing is easier with no shifts required and fewer characters to type. Absolutely not true in my case. wooledg:~$ ls -l /var/log/Xorg.0.log -rw-r--r-- 1 root root 46028 Apr 10 10:13 /var/log/Xorg.0.log wooledg:~$ ls -l ~/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 wooledg voice 24472 Jul 24 08:10 /home/wooledg/.local/share/xorg/Xorg.0.log How would your idea even *work*? You'd need some sort of system logging daemon. Something which runs with the privileges necessary to write to the log file, and which can accept log messages from unprivileged processes, perhaps by listening on a UNIX socket. Just making a suggestion. The X server can't write to /var/log because it doesn't have EUID 0 privileges any more. It writes to this file in the home directory because that's the only place it's sure to be able to open. There's simply no short-cutting it: the X server's log can be in either of these two places, and you need to check both. -- For more information, please reread. signature.asc Description: PGP signature
Re: video driver - new thread
On Sat, Jul 22, 2017 at 04:27:42PM -0400, Felix Miata wrote: > I don't often here fail to find a current /var/log/Xorg.0.log. I think what's > happening is the one in .local/share/ is getting copied to /var/log/ so that > it > remains available in the location people historically expect, where Googling > will suggest to look, plus the typing is easier with no shifts required and > fewer characters to type. Absolutely not true in my case. wooledg:~$ ls -l /var/log/Xorg.0.log -rw-r--r-- 1 root root 46028 Apr 10 10:13 /var/log/Xorg.0.log wooledg:~$ ls -l ~/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 wooledg voice 24472 Jul 24 08:10 /home/wooledg/.local/share/xorg/Xorg.0.log How would your idea even *work*? The X server can't write to /var/log because it doesn't have EUID 0 privileges any more. It writes to this file in the home directory because that's the only place it's sure to be able to open. There's simply no short-cutting it: the X server's log can be in either of these two places, and you need to check both.
Re: video driver - new thread
D. R. Evans composed on 2017-07-23 17:52 (UTC-0600): > D. R. Evans wrote: >> I am 99+% sure that the proprietary driver is being used, because the screen >> looks quite different during the boot sequence, and slightly different once I > I have discovered that if I open a console after switching to the NVIDIA > driver, the text is huge. The NVidia driver /directly/ affects only Xorg, not the vttys. That said, a very likely explanation for the huge text is that the proprietary nvidia driver installation resulted in placement of the string nomodeset on the kernel cmdline via a reconfiguration of /boot/grub/grub.cfg at the least and probably also /etc/default/grub. Checking kernel cmdline content can be done with 'cat /proc/cmdline' or inspecting the top few lines of the Xorg.0.log file. A brief test here, without any installed proprietary anything, and with nothing on the kernel cmdline to affect video modes anywhere, except for nomodeset, shows the result of ll /dev/fb* to be ls: cannot access /dev/fb*: No such file or directory. and the vttys to be running in 80x25 ("giant") text mode. Translated, lack of /dev/fb* means there is no framebuffer for the kernel to use to produce the nominal default size 16 vtty text in a likable physical size using a mode appropriate for a 1920x1200 display. As long as a proprietary driver needs kernel modesetting disabled, then to have something other than 80x25 on the vttys requires /something/ to select what configuration will be used via the kernel cmdline. To find the mode currently in use on a vtty, normally a simple fbset works. > I tried this solution (for Arch; I saw some posts about Debian, but nothing > that seemed to be a definitive solution): > https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution > and added the following two lines to the grub configuration file: > GRUB_GFXMODE=1280x1024x16,1024x768,auto > GRUB_GFXPAYLOAD_LINUX=keep > that had the effect of making the font considerably better during booting, but > I no longer saw a graphical login screen, and switching manually to the :0 > display with ctrl-alt-F7 just gave me a blank screen. (I chose the > 1280x1024x16 number more or less at random, just to try it and see what it > looked like.) I wouldn't expect those lines to override X in Jessie. Which DM is installed, GDM? SDDM? LightDM? KDM? > So I have removed those two lines, and returned to having a massive console > font (but a working desktop), but am wondering what the right way is in debian > jessie to get a more reasonable size of font on the console while still having > a desktop. The cited URL has more to offer than what you reported. It shows a fallback to deprecated vtty mode control via the vga= option, thus: "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792" Testing Jessie here, vga=792 produces "undefined mode number". 791 produces 16 bit 1024x768, a much more agreeable text size than 80x25. 794 produces 16 bit 1280x1024, so smaller yet text. 1920x1200 is not possible via vga=, as it's limited to VESA standard modes, none of which are widescreen. > FWIW, my (KDE) desktop resolution is 1920x1200. While David Wright's method of controlling text on the vttys is valid, it's a lot simpler for people who don't use the vttys much to control their vtty modes via kernel cmdline, thus Grub. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: video driver - new thread
On Sun 23 Jul 2017 at 17:52:19 (-0600), D. R. Evans wrote: > D. R. Evans wrote on 07/22/2017 11:48 AM: > > > I am 99+% sure that the proprietary driver is being used, because the screen > > looks quite different during the boot sequence, and slightly different once > > I > > I have discovered that if I open a console after switching to the NVIDIA > driver, the text is huge. > > I tried this solution (for Arch; I saw some posts about Debian, but nothing > that seemed to be a definitive solution): > > https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution > > and added the following two lines to the grub configuration file: > > GRUB_GFXMODE=1280x1024x16,1024x768,auto > GRUB_GFXPAYLOAD_LINUX=keep > > that had the effect of making the font considerably better during booting, but > I no longer saw a graphical login screen, and switching manually to the :0 > display with ctrl-alt-F7 just gave me a blank screen. (I chose the > 1280x1024x16 number more or less at random, just to try it and see what it > looked like.) > > So I have removed those two lines, and returned to having a massive console > font (but a working desktop), but am wondering what the right way is in debian > jessie to get a more reasonable size of font on the console while still having > a desktop. I use setfont. One advantage is that you can set different fonts on different consoles. Having xfonts-terminus installed, I use alias my-font-vast='setfont Lat15-Terminus32x16' alias my-font-huge='setfont Lat15-Terminus28x14' alias my-font-large='setfont Lat15-Terminus24x12' alias my-font-medium='setfont Lat15-Terminus20x10' alias my-font-small='setfont Lat15-Terminus14' alias my-font-tiny='setfont Lat15-Terminus12x6' and I have the bash function my-font-usr-share-consolefonts set up so that I can use command completion to remind me where the fonts are. This function loads an arbitrary font (by file completion) from that directory. The meat of the function is local FILENAME="$(basename "$1")"; setfont "${FILENAME%%.*}" Cheers, David.
Re: video driver - new thread
D. R. Evans wrote on 07/22/2017 11:48 AM: > I am 99+% sure that the proprietary driver is being used, because the screen > looks quite different during the boot sequence, and slightly different once I I have discovered that if I open a console after switching to the NVIDIA driver, the text is huge. I tried this solution (for Arch; I saw some posts about Debian, but nothing that seemed to be a definitive solution): https://wiki.archlinux.org/index.php/GRUB/Tips_and_tricks#Setting_the_framebuffer_resolution and added the following two lines to the grub configuration file: GRUB_GFXMODE=1280x1024x16,1024x768,auto GRUB_GFXPAYLOAD_LINUX=keep that had the effect of making the font considerably better during booting, but I no longer saw a graphical login screen, and switching manually to the :0 display with ctrl-alt-F7 just gave me a blank screen. (I chose the 1280x1024x16 number more or less at random, just to try it and see what it looked like.) So I have removed those two lines, and returned to having a massive console font (but a working desktop), but am wondering what the right way is in debian jessie to get a more reasonable size of font on the console while still having a desktop. FWIW, my (KDE) desktop resolution is 1920x1200. And if I execute hwinfo --framebuffer I get: root@homebrew:/home/n7dr# hwinfo --framebuffer 02: None 00.0: 11001 VESA Framebuffer [Created at bios.459] Unique ID: rdCR.jdAEt395qn6 Hardware Class: framebuffer Model: "NVIDIA GK208 Board - 2131" Vendor: "NVIDIA Corporation" Device: "GK208 Board - 2131" SubVendor: "NVIDIA" SubDevice: Revision: "Chip Rev" Memory Size: 14 MB Memory Range: 0xe900-0xe9df (rw) Mode 0x0300: 640x400 (+640), 8 bits Mode 0x0301: 640x480 (+640), 8 bits Mode 0x0303: 800x600 (+800), 8 bits Mode 0x0305: 1024x768 (+1024), 8 bits Mode 0x0307: 1280x1024 (+1280), 8 bits Mode 0x030e: 320x200 (+640), 16 bits Mode 0x030f: 320x200 (+1280), 24 bits Mode 0x0311: 640x480 (+1280), 16 bits Mode 0x0312: 640x480 (+2560), 24 bits Mode 0x0314: 800x600 (+1600), 16 bits Mode 0x0315: 800x600 (+3200), 24 bits Mode 0x0317: 1024x768 (+2048), 16 bits Mode 0x0318: 1024x768 (+4096), 24 bits Mode 0x031a: 1280x1024 (+2560), 16 bits Mode 0x031b: 1280x1024 (+5120), 24 bits Mode 0x0330: 320x200 (+320), 8 bits Mode 0x0331: 320x400 (+320), 8 bits Mode 0x0332: 320x400 (+640), 16 bits Mode 0x0333: 320x400 (+1280), 24 bits Mode 0x0334: 320x240 (+320), 8 bits Mode 0x0335: 320x240 (+640), 16 bits Mode 0x0336: 320x240 (+1280), 24 bits Mode 0x033d: 640x400 (+1280), 16 bits Mode 0x033e: 640x400 (+2560), 24 bits Mode 0x0345: 1600x1200 (+1600), 8 bits Mode 0x0346: 1600x1200 (+3200), 16 bits Mode 0x034a: 1600x1200 (+6400), 24 bits Config Status: cfg=new, avail=yes, need=no, active=unknown root@homebrew:/home/n7dr# Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: video driver - new thread
Curt composed on 2017-07-22 15:58 (UTC-0400): > Felix Miata wrote: >> D. R. Evans composed on 2017-07-22 13:06 (UTC-0600): >>> Reco wrote: grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log >>> [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log >>> grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or >>> directory >>> [HN:~] >> I don't know why he suggested that: > KMS rootless X indeed puts the log in ~/.local/share/xorg. As it's > enabled by default for the nouveau driver since Squeeze, the "No such > file or directory" message indicates the OP is using the proprietary > driver, for which KMS must be enabled manually. Rather than "suggested that" I should have written "suggested glx as search string". I don't often here fail to find a current /var/log/Xorg.0.log. I think what's happening is the one in .local/share/ is getting copied to /var/log/ so that it remains available in the location people historically expect, where Googling will suggest to look, plus the typing is easier with no shifts required and fewer characters to type. > Kind of a roundabout, teach a fish to fly kind of thing, but Reco is > twisted. > Actually just kidding. > How 'bout > grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log Is a mere mortal going to know, seeing the following, which driver is actually in use? # grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log [22.731] (II) Module modesetting: vendor="X.Org Foundation" .. [22.731] (II) Module fbdev: vendor="X.Org Foundation" .. [22.731] (II) Module vesa: vendor="X.Org Foundation" Someone using a file viewer (e.g. MC -> F3) rather than grep is going to spot a large mass of similar *(0) lines faster than one short string in a file with 300 or more lines. Another grepping option: # grep Output /var/log/Xorg.0.log [22.851] (II) modeset(0): Output VGA-0 has no monitor section [22.864] (II) modeset(0): Output HDMI-0 has no monitor section [22.864] (II) modeset(0): Output HDMI-1 has no monitor section [22.879] (II) modeset(0): Output VGA-0 disconnected [22.879] (II) modeset(0): Output HDMI-0 connected [22.879] (II) modeset(0): Output HDMI-1 disconnected [22.879] (II) modeset(0): Output HDMI-0 using initial mode 1920x1200 > But then if the OP had been using the nouveau driver, he'd get a "No such > file or directory" message. > Now a word from our sponsor.-- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: video driver - new thread
On 2017-07-22, Felix Miatawrote: > D. R. Evans composed on 2017-07-22 13:06 (UTC-0600): > >> Reco wrote: > >>> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log > >> [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log >> grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory >> [HN:~] >> > > I don't know why he suggested that: > KMS rootless X indeed puts the log in ~/.local/share/xorg. As it's enabled by default for the nouveau driver since Squeeze, the "No such file or directory" message indicates the OP is using the proprietary driver, for which KMS must be enabled manually. Kind of a roundabout, teach a fish to fly kind of thing, but Reco is twisted. Actually just kidding. How 'bout grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log But then if the OP had been using the nouveau driver, he'd get a "No such file or directory" message. Now a word from our sponsor. -- “We’ll sit around talking about the good old days, when we wished that we were dead.” --Samuel Beckett, speculating on the nature of the afterlife.
Re: video driver - new thread
D. R. Evans composed on 2017-07-22 13:06 (UTC-0600): > Reco wrote: >> grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log > [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log > grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory > [HN:~] > I don't know why he suggested that: $ inxi -c0 -G Graphics: Card: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller Display Server: X.Org 1.17.2 drivers: modesetting (unloaded: fbdev,vesa) Resolution: 1920x1200@60.0hz GLX Renderer: Mesa DRI Intel Haswell Desktop GLX Version: 3.0 Mesa 11.0.8 # grep glx /var/log/Xorg.[0-9]*.log /var/log/Xorg.0.log:[22.700] (II) LoadModule: "glx" /var/log/Xorg.0.log:[22.701] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so /var/log/Xorg.0.log:[22.727] (II) Module glx: vendor="X.Org Foundation" /var/log/Xorg.1.log:[2946089.809] (II) LoadModule: "glx" /var/log/Xorg.1.log:[2946089.809] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so /var/log/Xorg.1.log:[2946089.810] (II) Module glx: vendor="X.Org Foundation" If the NVidia driver is in use, Xorg.[0-9].log will have /many/ lines in sequence that include: NVIDIA(0) If Nouveau: NOUVEAU(0) If modesetting: MODESET(0) If Intel: INTEL(0) # grep -i MODESET /var/log/Xorg.0.log | wc -l 233 If Radeon: RADEON(0) If Amdgpu AMDGPU(0) -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: video driver - new thread
Hans wrote on 07/22/2017 11:55 AM: > Maybe try to add a file /etc/X11/xorg.conf (ask google, how it has to look), > and in it set the driver "nvidia". > nvidia-xconfig created such a file, and the driver in it is set to "nvidia", so I think that is indeed the confirmation I was looking for. Thank you. > Make sure, the nouveau kernel driver is blacklisted. > How do I do that? (Although it doesn't seem to be necessary.) > BTW: Is the proprietrary driver compatible with latest xserver-xorg again? > I have no idea how to answer that, I'm afraid. If you can tell me what commands I should try in order to get that information, I'll happily try them. The system here (jessie, 64-bit) is completely up to date, so it should be using the latest version of everything that is supported in jessie. (It's on my to-do list to move to stretch, but given that the first system on which I tried that produced a not-particularly-pleasant experience, with one issue still unresolved, I'm waiting for a bit before upgrading my main desktop system.) Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: video driver - new thread
Reco wrote on 07/22/2017 12:37 PM: > grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log [HN:~] grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log grep: /home/n7dr/.local/share/xorg/Xorg.[0-9]*.log: No such file or directory [HN:~] Doc -- Web: http://enginehousebooks.com/drevans signature.asc Description: OpenPGP digital signature
Re: video driver - new thread
Hi. On Sat, 22 Jul 2017 11:48:42 -0600 "D. R. Evans"wrote: > As my old thread has been hijacked, I thought that I'd better start a new one. > > Teemu Likonen wrote on 07/17/2017 03:09 PM: > > D. R. Evans [2017-07-17 14:19:32-06] wrote: > > > >> Beginning a couple of weeks ago, I started to experience occasional > >> freezes or > >> sudden blank screens on my 64-bit jessie system. > > > >> Jul 17 13:58:23 homebrew kernel: [24262.075187] nouveau E[ DRM] GPU > >> lockup > >> - switching to software fbcon > >> > >> I don't know how a particular driver gets chosen by the system, but is > >> there a > >> different driver I could try? > > > > I have an Nvidia card and experienced complete lockups with nouveau > > driver. Solution: Install nvidia-driver packages and all is working > > well. Just one additional problem: non-free software. > > > > I have installed the nvidia-driver package. > > At that point X did not start on boot, so I installed nvidia-xconfig and ran > it. It gave half a dozen errors, but on reboot X started and looks good. > > How do I confirm that I am actually using the proprietary driver rather than > nouveau? grep -i glx ~/.local/share/xorg/Xorg.[0-9]*.log If you see nvidia in the result - you're using proprietary driver. Reco
Re: video driver - new thread
Maybe try to add a file /etc/X11/xorg.conf (ask google, how it has to look), and in it set the driver "nvidia". Make sure, the nouveau kernel driver is blacklisted. BTW: Is the proprietrary driver compatible with latest xserver-xorg again? Best regards Hans > Thanks to people for their helpful suggestions about installing the > proprietary driver (sorry it took so long to actually get it done: I had > some work in progress for a client, and didn't want to run a risk of ending > up without a working graphical desktop. That work ended yesterday, so this > is the first time it's felt safe to try the switch to the new driver.) > > Doc