Dynamically assign major opcodes for extensions

[Syudagye]

Opcodes 0-127 are for the base protocol requests, so they are static and won't change.
But opcodes 127-255 are for extensions and are dynamically assigned by the X server at startup, so they can't be statically set within the macro syntax or Request trait constant.
https://www.x.org/wiki/Development/Documentation/Protocol/OpCodes/

So the macro syntax and the trait definition needs to be adapted to support extensions.

[Syudagye]

I thought of two ways this could be dealt with

• using mutable static variables
• using fields in requests

Static Variables

Each extension would have a static variable on it's module that contains the major opcode.
This variable will be accessed by each requests to retrieve the assigned major opcode of the extension.
The major opcode will be set by the api crate (e.g. X.RS).
Of course, this mutable static will not be exposed through the api crate.

// On the mod file of the extension
pub static mut MAJOR_OPCODE: u8 = 0;

// Extension request format (using `xrb_derive!`)
pub struct SomeRequest: Request(path::to::MAJOR_OPCODE, 0) { /* */ }

This will generate the following Request impl:

impl Request for SomeRequest {
    fn major_opcode() -> u8 {
        // using unsafe here because of the mutable static
        unsafe { path::to::MAJOR_OPCODE }
    }
    const MINOR_OPCODE: Option<u8> = Some(0);
}

This method involves the usage of unsafe, because of mutable static variables, but this shouldn't be a big problem, since writing to this variable would only happen on initialization (for exemple when creating a Client of some sort on X.RS), and after that it only involves reading.

Core requests

Core requests only require one opcode, so we could use the current syntax and it would work

pub struct SomeCoreRequest: Request(7) { /* */ }

// would result to
impl Request for SomeCoreRequest {
    fn major_opcode() -> u8 {
        7
    }
    const MINOR_OPCODE: Option<u8> = None;
}

I've experimented with this on the opcode-fix-static branch.

Fields

This method would be just adding a field to the request that contains the major opcode.
This way, the api crate would be able to pass the opcode on the object creation.

pub struct SomeRequest: Request(7) {
    #[major_opcode]    
    pub major_opcode: u8
}

// could result to
impl Request for SomeRequest {
    fn major_opcode(&self) -> u8 {
        self.major_opcode
    }
    const MINOR_OPCODE: Option<u8> = Some(7);
}

Core Requests

We need a way to make the difference between core requests and extensions requests, so maybe some special syntax would be involved, but also a new trait.
Here is an idea of how it could look like:

pub struct SomeCoreRequest: CoreRequest(7) { /* */ }

// Could result to
impl Request for SomeCoreRequest {
    fn major_opcode(&self) -> u8 {
        <Self as CoreRequest>::MAJOR_OPCODE
    }
    const MINOR_OPCODE: Option<u8> = None;
}
impl CoreRequest for SomeCoreRequest {
    const MAJOR_OPCODE: u8 = 7;
}

[Antikyth]

I think it would definitely be better as a field. Supplying the major opcode can be the job of X.RS/whatever library, which would likely keep track of the extensions and their major opcodes in the Client struct.