If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

A Preview Of Kernel-Based Mode-Setting

Phoronix: A Preview Of Kernel-Based Mode-Setting

There are many new and innovative features brewing within the X.Org development community right now -- among the many are Gallium3D, the TTM memory manager, and MPX (Multi-Pointer X) -- but one of the features that has risen towards the top of the list and delivers visible benefits to the end-user is kernel-based mode-setting. As implied by its name, kernel mode-setting involves moving the mode-setting code for video adapters from the user-space X server drivers into the Linux kernel. This may seem like an uninteresting topic for end-users, but having the mode-setting done in the kernel allows for a cleaner and richer boot process, improved suspend and resume support, and more reliable VT switching (along with other advantages). Kernel mode-setting isn't yet in the mainline Linux kernel nor is the API for it frozen, but Fedora 9 shipping next month will be the first major distribution carrying this initial support. In this article we're looking more closely at kernel mode-setting with the Intel X.Org driver as well as showing videos of kernel-based mode-setting in action.

By the way, in the case of the X driver, does it just have a "dummy" ddx that passes everything to the kernel modesetting driver, or is there an actual structural change? Will there be any changes to how and where acceleration (EXA, Render, OpenGL) is handled?

By the way, in the case of the X driver, does it just have a "dummy" ddx that passes everything to the kernel modesetting driver, or is there an actual structural change? Will there be any changes to how and where acceleration (EXA, Render, OpenGL) is handled?

Initially we are just going to use the normal DDX, with some common code, however for keeping compat with current randr-1.2 implementations, we'll need some impedance matching in the DDX layer between the kernel and randr interfaces.

nothing else will move, however we will be restricting what the X driver can access, i.e. no more direct register access, all accel should be done via kernel command submission etc.. so for Intel we have had to switch the DDX from using the ring directly to using batchbuffers and submitting those to the kernel,

the final point we want to reach is probably a driver with kernel modesetting/EXA/TTM and nothing else.

No Intel has no other discrete cards after the i740, but they will soon release some based on their new architecture (which in turn is based off the x86 instruction set), the name currently eludes me, as does the estimated time frame of its release.