Figure out how to deal with wl_pointer::frame for relative pointer and the like

[ids1024]

It seems the expected behavior is for relative_motion to be followed by frame, probably in the same frame as the motion. In cosmic-comp I made this work by calling relative_motion before motion (pop-os/cosmic-comp#167), but that's going to be a problem with pointer constraints where only relative_motion events may occur.

[ids1024]

One solution to this for (relative) motion events is to combine the two events into one with 2 Options:

/// Pointer motion event
#[derive(Debug, Clone)]
pub struct AbsoluteMotion {
    /// Location of the pointer in compositor space
    pub location: Point<f64, Logical>,
    /// Serial of the event
    pub serial: Serial,
}

/// Relative pointer motion event
#[derive(Debug, Clone)]
pub struct RelativeMotion {
    /// Motional vector
    pub delta: Point<f64, Logical>,
    /// Unaccelerated motion vector
    pub delta_unaccel: Point<f64, Logical>,

}

/// Pointer motion event
struct MotionEvent {
    pub absolute: Option<AbsoluteMotion>,
    pub relative: Option<RelativeMotion>,
    /// Timestamp in microseconds
    pub utime: u64,
}

wlroots has a separate wlr_seat_pointer_notify_frame function. Making frame calls explicit like that is also a possibility.

[Drakulix]

Given we had some issues in the past with grouping axis-events, uncertainty where pointer gestures fit here and now the relative-pointer protocol, we might want to consider making frame explicit. That would also play nice with any further protocols relying on this event.