| View previous topic :: View next topic |
| Author |
Message |
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
 Posted: Sat Nov 03, 2012 2:37 am Post subject: Config_drm_i915_kms -- wtf?? |
 |
|
I'm upgrading from the 3.5 series kernel to the 3.6 series kernel on all my PCs. For my Intel Atom based netbooks with the: | Code: | | VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03) |
I see the following message I've never seen before: | Code: | │ CONFIG_DRM_I915_KMS:
│
│ Choose this option if you want kernel modesetting enabled by default,
│ and you have a new enough userspace to support this. Running old
│ userspaces with this enabled will cause pain. Note that this causes
│ the driver to bind to PCI devices, which precludes loading things
│ like intelfb |
Based on emperical observation and multiple close re-readings of this kernel help fragment, my understanding is that I can either configure to use the 'intelfb' {with the 'xf86-video-vesa' driver for GUIs} OR I can use the kernel DRM and KMS {with the xf86-video-intel driver} but not both!?!?!
i.e. Either I have the computer boot using the frame buffer and have clt-alt-F1 through F6 as usual with {an optional} VESA driven F7 (through F12) set of screens OR I have the computer boot in GUI mode at F7 {using the xf86-video-intel diver} with no access to F1-F6?
Am I understanding this correctly?
What's happening is if I want to use kernel DRM and KMS is set for Intel GPUs and I do not have an active 'xdm' at boot then the screen comes up 'off'. It's still a normal login and I can log in 'blind'. I can even {blindly} execute something like: | Code: | | XSESSION="razor-session" startx |
and the graphical window manager will start and display correctly.
But ... This is for real? Intel really precludes use of the frame buffers with kernel mode setting? Really???
Currently, I'm accepting the need to configure my netbooks for a graphical login. I was just rather surprised at the above limitation and wanted to confirm it.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
 |
Jaglover
Watchman
Joined: 29 May 2005
Posts: 8291
Location: Saint Amant, Acadiana
|
|
| Back to top |
|
|
dufeu
l33t
Joined: 30 Aug 2002
Posts: 924
Location: US-FL-EST
|
| Posted: Sat Nov 03, 2012 4:57 am Post subject: |
|
|
| Jaglover wrote: | | No worries, you will have consoles with KMS. |
I can start consoles either as GUI based terminals or remotely via ssh. It's just weird to me to not be able to do ctl-alt-F1-6. The flip side of that coin is I can't run multiple GUI sessions. Or rather, I don't remember how to initiate multiple GUI sessions from within a GUI session.
What I normally do is log in at CLI {no 'xdm' in rc}. This puts me in vt1 at boot.
Then I can do something like: | Code: | | XSESSION=kde-4 startx -- :1 |
From there, I can do ctl-alt-F2 to get to vt2. Login as a different user. Then do somthing like: | Code: | | XSESSION="razor-session" startx -- :2 |
This allows me to log in one GUI user on vt7 then a second GUI user on vt8.
With this new DRM/KMS mutually exclusive with intelfb frame buffer, I can't do this anymore. I _can_ do it using just the intelfb using the VESA driver for the GUI sessions .. but ..
Not really a problem since these netbooks don't really have the capacity to graphically do this kind of stuff anyway.
It's really not a theoretical issue. I run wireshark as a different user in a separate razorqt session. Yes, I know I could open a terminal session and sudo wireshark that way as a different user. But I really do occasionally run simultaneous multiple complete desktops as multiple users using different WMs. Under these conditions, being able to drop to vt1-6 can be important when a GUI screws up.
Trying to do this with Intel's set up means I have to relearn how to initiate a new GUI session from within a GUI session. Something I haven't done for years. And I loose the safety net of getting directly to vt1-6. Instead, I would need to ssh in from a different PC.
_________________
People whom think M$ is mediocre, don't know the half of it. |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Sat Nov 03, 2012 6:54 am Post subject: |
|
|
@dufeu: you're misunderstanding things; for intel/KMS the answer is CONFIG_FRAMEBUFFER_CONSOLE. That works with ctl-alt-F1-6 just fine - actually, likely better than intelfb ever did. The thing is that most of CONFIG_FB_* options conflicts with it.
Also, it's a really old topic - xf86-video-intel has been KMS-only for quite awhile. |
|
| Back to top |
|
|
wcg
Guru
Joined: 06 Jan 2009
Posts: 588
|
| Posted: Sat Nov 03, 2012 11:17 pm Post subject: |
|
|
(NB: I do not have this hardware, I am simply extrapolating from the way
that nouveau works on nvidia hardware. nouveau implements its own
internal framebuffer support.)
If you have the intel dri kernel driver with kms enabled, and it does not
implement its own framebuffer internally, and you do not enable intelfb,
CONFIG_FB_VESA, or one of the other framebuffer drivers, then the
kernel will boot with the video in vga mode. Virtual consoles still work
in vga mode, but you don't get all of the fancy resolutions, colorspaces,
etc that framebuffers enable. (I do not know how this affects xorg,
but I used to start xorg with the nv driver with no framebuffer
enabled in the kernel, and both virtual consoles and xorg worked.)
<edit:>
This assumes you have the vga console enabled in the kernel.
"Why is it not enabled by default?" Some systems have no
display hardware, for example, so it would be a waste of
kernel memory.
</edit>
If you have the intel dri kernel driver with kms enabled, and it implements
its own internal framebuffer, then it will likely come up with the
framebuffer enabled, which would conflict with intelfb, CONFIG_FB_VESA,
or any other framebuffer drivers that you enabled. You would still
need to enable CONFIG_FB and perhaps the other not-driver-specific
CONFIG_FB_CFB* (or CONFIG_FB_SYS*) options for the framebuffer
to work. You may have to pass a "video=" set of framebuffer parameters
for screen size, color bits, etc at boot or when the module is loaded
if it is compiled as a module.
That would be my guess. (You can see the vga console at very early
boot when booting a kernel with working framebuffer support, because
the kernel messages are displayed on the vga console before the
framebuffer driver is loaded and the kernel transfers the display
of boot messages to display through the framebuffer.)
The menuconfig help text sounds like the driver has implemented
its own framebuffer for use with dri+kms support (which is why
it would conflict with intelfb).
_________________
TIA |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Desktop Environments
