Yes. Mode shifts are not performance critical (yet it is obviously
critical that you can do them regardless of what happens to the main
graphics part), so it makes sense to have those parts done by an external
"more trusted" entity that does nothing but mode shift.
So when the X server wants to shift modes due to Ctrl-Alt-'+'/'-', it just
tells the mode server to do it for it (sending a signal, or having a pipe
open when it forked it off or whatever).
Notice that X already used to do something like this. Remember back when
XFree86 didn't know enough about some graphics card clock drivers, and
with some cards you had to use an external command to set the graphics
clock? I don't think they do that any more, but the point is that X has
had "external" help for things like this before too..
And then, whether that "more trusted" entity is a kernel module or a
deamon or whatever is immaterial as far as I'm concerned, and I wouldn't
have any problems with XF86 just doing an "insmod" instead of forking a
process. However, forking a separate process has many advantages, not the
least of which is portability (XF86 still works on other architectures
than Linux).
And even more importantly - I think that the _first_ step should be to do
it in user land, and only once people have shown that it doesn't work that
way should they consider a kernel approach. Again, I want to complain
about the fact that people just automatically thought this needed lots of
kernel support, obviously without ever even thinking about user-level
approaches.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html