As it was already pointed out WDM, KMDF or UMDF has rather limited
usefulness when it comes to display drivers.
Depending on OS version you have following options to choose from:
* XDDM - pre-Vista display driver model. It’s fully supported on win
2k, XP. You can still use it on Vista and on Win7 (with some hacks
IRC). It’s not supported on Win8 and higher OS. XDDM is framebuffer
based (DX support is possible but not mandatory). XDDM allows to
create virtual adapters and mirror drivers. You could also mix
different versions of drivers (even from different HW vendors). XDDM
consists of kernel mode miniport (talks to HW) and kernel mode
(session space) display driver (implements GDI operations).
* WDDM - introduced on Vista and currently used on latest OS versions,
they have to implement DX functionality to be able to have Aero Glass
interface (3d, HW accelerated UI). They are surface rather than
framebuffer based (see desktop composition and DWM). WDDM 1.0 allows
to have only one version of driver loaded (so it was not possible to
have two adapters handled by two different WDDM drivers). Virtual
adapters and mirror drivers are not supported (though they are
possible to achieve with substantial effort). Full WDDM driver
consists of two components: kernel mode miniport (talks to the HW and
implements stuff like VidPn) and user mode driver (implements DirectX
elements).
* KMDOD - kernel mode display-only driver, introduced on Win8. It’s a
very simple WDDM driver where you have access with some parts of VidPn
and framebuffer. It uses built-in software renderer (see WARP) to
implement DirectX operations. Basic Display (that uses this model)
replaced old vgasave driver on Win8 and hence Aero Glass UI is used
even in safe mode.
There are no dedicated books about display drivers on Windows
(although I vaguely recall some single chapters related to XDDM in
some rather old positions about driver development). As long as WDDM
goes there is nothing except from MSDN documentation. There was rather
useless WDDM (for R200) example available in some older WDK (IRC 6000
and 6001). As for KMDOD there is working sample in WDK 8.
I wouldn’t count on someone telling you X, Y, Z as display drivers
have rather steep learning curve (especially WDDM ones). I also
wouldn’t recommend it as learning exercise but this probably depends
on your background and experience.
Kris
On Tue, Dec 24, 2013 at 2:37 AM, wrote:
> My understanding, from talking to those who have written display drivers,
> is that the bulk of the code deals with rendering images. The default VGA
> driver does it all in software, more sophisticated display drivers send
> commands to the GPU via writing to various onboard registers.
>
> This does not mean that for very sophisticated graphics cards the code is
> smaller or simpler than the default VGA driver; one person I met claims to
> have “written the NVidia operating system…you know, that vast body of
> code that has the little linux driver attached.” He told me that his
> driver has more lines of code than the linux core, that is, linux without
> drivers.
>
> The complex concepts of display drivers, such as “surfaces”, are unique to
> graphical drivers, and are not found anywhere else. The WDM-like
> components, such as IRPs, are not relevant to the bulk of the effort.
>
> Since display drivers live in the kernel, UMDF would have no relevance.
>
> And not to be a wet-blanket, but do you seriously expect to understand
> KMDF, UMDF, or even WDM, in month? Note that many of the complex question
> posed here are from people with /years/ of device driver experience, who
> are now stumped by third-order effects in the more obscure corners of
> driver-writing knowledge. What you /can/ accomplish in a month is a good
> grounding in concepts, vocabulary, building-and-debugging, and first-level
> effects, with the possibility of learning about some second-level effects.
> Which is good, but don’t expect to emerge at the end of the month with
> the same grasp of the subtleties as Peter, Tony, Scott, Don, or many
> others (I just happen to know all those guys from past conferences or
> other backgrounds, no slight to the many highly-competent people whose
> names I didn’t mention). It will not be a waste of time, but don’t expect
> miracles. This stuff is intrinsically complex, which is one of the
> reasons I rant about the introduction of unneeded complexity whose avowed
> purpose is to solve problems whose existence has not been demonstrated
> (the classic “I want to share kernel memory with user space” issue, a
> fairly exotic technique best avoided until you have several years’
> experience). So, after a month doing KMDF, you will have useful skills
> which you will then spend several years honing. Ditto UMDF, which is
> probably most useful for USB devices. Maybe a reasonable project would
> involve learning filter drivers; others can comment on whether or not this
> would make sense. But other than the compiling-and-debugging, and signing
> (which I omitted from the first enumeration), nothing will have any
> relevance to display drivers, at least the graphical parts.
> joe
>
>> Don’t I need any knowledge about WDF, KMD, UMD to work with display
>> drivers? If not, what is exactly there that I should learn?
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kris