Put Device and Master methods into traits.

[trissylegs]

Rationale

1. Cards have been split.

There are now three kinds of Drm devices. card, render and control nodes. A typical setup might look like this:

$ ls /dev/dri
card0
controlD64
renderD128

(From memory, not running Linux right now. Mine also has another for my discrete card)

We can split some things into control, some things into render (and leave somethings on both).

2. There are multiple ways of getting and interacting with devices that have different semantics.

• Open /dev/dri/card? set_master until exit or manually unset when TTY says to switch.
• Get a dev from loginctl. Use it as master until it says pause. Resume when unpause is send.
• Open render, make buffers, send via wayland/x11/surface flinger.
• Open two devices, render on descrete card and scanout on integrated.
• Use device from gbm instead of our own type.

Design:

pub trait DrmNode {
    unsafe fn ioctl<T:DrmIoctl>(&self, arg: &mut T) -> io::Result<()>;

    fn version(&self) -> Result<Version> {
        // Done for you
    }
    // more
}

pub trait Card: DrmNode {
    type Authenticated: Render;
    type Master: Card+Render+Master;
    pub fn set_master(self) -> Result<Self::Master>;
    pub fn auth_magic(self, magic: u32) -> Result<Self::Authenticated>;
}

pub trait Master {
    type Card;
    pub fn unset_master(self) -> Result<Self::Card>;
}

pub trait Render: DrmNode {
    fn create_dumbbuf(&self) -> Result<DumbBuf>;
    // etc.
}

pub trait Control: DrmNode {
    fn set_crtc(&self, 
        crtc: Id<Crtc>, 
        fb: Option<Id<Fb>>, 
        x: u32, y: u32, 
        connectors: &[Id<Connector>],
        mode: Option<&ModeInfo>)
    {
        // stuff
    }
}

This does expose ioctl and DrmIoctl, but I did plan on doing that anyway.