1 |
On Monday 04 July 2011 14:15:12 Mark Knecht did opine thusly: |
2 |
> On Mon, Jul 4, 2011 at 1:57 PM, Alan McKinnon |
3 |
<alan.mckinnon@×××××.com> wrote: |
4 |
> > On Monday 04 July 2011 13:47:28 Mark Knecht did opine thusly: |
5 |
> >> On Mon, Jul 4, 2011 at 1:40 PM, Alan McKinnon |
6 |
|
7 |
|
8 |
|
9 |
> >> so does bootsplash run using framebuffer or is it completely |
10 |
> >> different? |
11 |
> > |
12 |
> > I have no idea actually. I could say it must run in a |
13 |
> > framebuffer-like abstraction but that is obvious and doesn't |
14 |
> > tell you anything you don't already know. |
15 |
> > |
16 |
> > Spock is the dev that knows most about these things, a good |
17 |
> > first |
18 |
> > research point would be to search his name and find related |
19 |
> > docs. |
20 |
> > |
21 |
> > Sorry I can't be more help - I have the concepts in my head but |
22 |
> > not the facts |
23 |
> |
24 |
> I appreciate the info. No worries about that. |
25 |
> |
26 |
> I think the other point I'm missing here is whether KMS is actually |
27 |
> implementing anything graphical, like a framebuffer, or whether it's |
28 |
> just moving _choices_ about graphics into the kernel and out of X? |
29 |
|
30 |
By definition a framebuffer is a chunk of memory, and my understanding |
31 |
is that KMS does implement one (nouveau definitely provides a |
32 |
framebuffer, and it conflicts with all other framebuffers - you can't |
33 |
have more than one in the kernel at all). The clue is in the name: |
34 |
Kernel Mode Switching. It deals with all the low-level commands to set |
35 |
modes in the graphics card so that X doesn't have to do it itself. |
36 |
|
37 |
> |
38 |
> I have an Intel i5-661/Intel MB based machine which is the only one |
39 |
> I use KMS for at this time. On that machine I was instructed to use |
40 |
> KMS by the Intel-Gfx devs to get their driver working at all. A |
41 |
> nice side benefit was that it resulted in better text in the |
42 |
> console during boot. However I don't see anything 'graphics like' |
43 |
> on that box just using KMS so I suspect that while I've enabled |
44 |
> technology that allows the kernel to manage graphics that I haven't |
45 |
> told the kernel to actually do so. I don't know though. |
46 |
|
47 |
When you speak of graphics in the context of framebuffers and |
48 |
consoles, it's better to think in terms of "able to do what graphics |
49 |
does" i.e. address a gigantic number of pixels individually. The fact |
50 |
that you are not running any software capable of rendering graphics |
51 |
doesn't reduce the fact that the means to do is there. |
52 |
|
53 |
> All of my other machines are NVidia based and use the closed source |
54 |
> driver so my understanding on those is that KMS doesn't apply. |
55 |
|
56 |
Yes, that's true. |
57 |
|
58 |
nVidia does it's own bizarre weird stuff that will forever more be |
59 |
incompatible with the entire free software world <sigh> |
60 |
|
61 |
|
62 |
> I'm curious, however, about my Gentoo VMs. Can KMS run on a VM's |
63 |
> kernel and do anything useful there? This is more for learning and |
64 |
> not about any practical need at this time. |
65 |
|
66 |
From my understanding, this topic gets yucky. There's a whole bunch of |
67 |
ways this could be done, from software emulation to para- |
68 |
virtualization to full virtualization. Emulation is easy - KMS in the |
69 |
guest sees what looks for all the world like hardware so everything |
70 |
works if KMS supports the emulated card (albeit slowly). For |
71 |
everything else, you'd need kernel drivers intercepting efforts to |
72 |
talk to the hardware and be traffic cop. My brain is already spinning |
73 |
on this so please excuse me while I go dunk my head in a bucket and |
74 |
not think about it anymore :-) |
75 |
|
76 |
|
77 |
|
78 |
|
79 |
|
80 |
|
81 |
|
82 |
> |
83 |
> Cheers, |
84 |
> Mark |
85 |
-- |
86 |
alan dot mckinnon at gmail dot com |