lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 28 Oct 2014 02:32:08 -0400
From:	Michael Shell <list1@...haelshell.org>
To:	linux-kernel@...r.kernel.org
Subject: Standard VGA console with DRI/DRM under X?



  Greetings,

Well, I want to be able to have my cake and eat it too. I want to be able to
have the standard VGA/"hardware" classic console (not the framebuffer) but
I still want the /dev/dri/cardX devices so that I can use DRI under Xorg.

Is this possible and if not, why not?


(I do hope I'm not bring up an issue with an obvious fix, but my searching
 has not yielded an answer yet. For the record, I'm running modern kernel
 (3.16.3) with much older x86 hardware [r100 Radeon video card].)


If I boot with the kernel nomodeset option I can get the classic
VGA/"hardware" console, but then I lose support for DRI/DRM:

Oct 27 15:11:09 X kernel: [drm] Initialized drm 1.1.0 20060810
Oct 27 15:11:09 X kernel: [drm] VGACON disable radeon kernel modesetting.
Oct 27 15:11:09 X kernel: [drm:radeon_init] *ERROR* No UMS support in radeon module

and glxgears et al. turns slow. In more modern Xorg releases, DRI is
required for all hardware acceleration, so having /dev/dri/cardX is very
important:

http://askubuntu.com/questions/463142/why-x-is-relying-on-software-instead-of-hardware-with-nomodeset-kernel-paramet


One reason I do not wish to use the framebuffer console is because of the
small font. 160 columns makes it difficult to tell which [OK] belongs with
which service. The selection of console fonts should always include a
set that gives us an 80 column screen and the docs should point this out.

And I dislike any blanking or video mode changes during boot.

Can't the kernel just declare that it is capable of setting the video mode,
provide the /dev/dri/cardX devices and leave the console alone, but still
allow Xorg to call for a new mode and use /dev/dri/cardX if/when it sees fit?

In an ideal world, there would be some kernel option such as fbcon=no.

In the kernel Documentation fbcon.txt it mentions "fbcon=map:1 tells fbcon not
to take over the console." But, IIRC, from my tests I wasn't able to use this
to get a VGA/"hardware" console and still be able to have /dev/dri/cardX devices.



    Cheers and thank you,

    Mike Shell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ