re: XVR-1000 (Re: pkgin missing on repo sparc64)

[matthew green <mrg%eterna.com.au@localhost>]

> > In summary, there would be both a kernel part and a userland part
> > (an X11 driver).  If a DRM driver exists, there is more logic in the
> > kernel.  Otherwise, most of the logic is in the X11 driver.
> 
> OK thanks for the info. So if I understand it correctly:
> 
> DRI (x86 and arm) - X11 opens /dev/dri/card0 and then uses
> various ioctls to set display mode and output graphics on the screen.
> There is no direct access to graphics card memory and registers, i.e.
> everything is abstracted via DRI ioctls.

x86 and arm also can have non-DRI.  we don't support modern
cards, and these fall back to vesa or wsfb drivers.

there's also modesetting driver, which pushes the majority
of the card-specific code into libdrm itself.

there are some generic ioctls, but also many card-specific
ioctls.  there's not really a generic API to do everything.

> Framebuffer (sparc64) - X11 mmap()s /dev/fb and has direct access to
> graphics card memory and registers. There is no DRI or any other
> common APIs, so to output graphics on the screen, X11 has to write to
> mmap()ed memory regions.

as i understand it, there are additional accelerations
available for some of these drivers, depending mostly on
the non-DRI based kernel driver though.
 
> So does this mean that from X11 point of view, with DRI there needs to
> be just one user space driver, i.e. X11 talking to DRI? In this case the
> DRI implements low-level drivers that actually talk to different
> graphics cards, plus some user space library like libdrm, that provides
> APIs for X11 and potentially translates C function calls into DRI
> ioctls?

in X11, there can be any number of applications talking
to the kernel drm to ask it to draw things.  for instance
when you run GL apps, the app talks to Mesa talks to
libdrm and libdrm_$card talks to kernel driver, which
processes the requests.

the "modesetting" xf86 "video" driver, which obsoletes
almost all of the card-specific code in the xf86 driver
and instead uses minimal code that talks via libdrm
and libdrm_$card.  it may provide fewer total features
and depend heavily on GL to provide services.  eg, the
Xvideo extension is missing.

(as i understand it, wayland works via a "modesetting"
equivalent driver that talks to Mesa and libdrm*.  i am
could be wrong about this part..)


.. this seems long for trying to be short.  it's a large
subject...


.mrg.