How to read monitors specifications ? like:

• relative positions and states, like: "left, right, bottom, top".
• horizontal flip, vertical flip
• rotation on axe x or y

How to get the currently used frequency mode ?

Can Monitor an ScreenResourses have clone trait?

Hey! Thanks for the crate :)
I know nothing about xrandr, but I'm looking to implement toy-project to automatically activate/deactivate my external monitors when I'm connecting/disconnecting them.
I noticed that when I'm just pluggin in the external monitor it appears in the xrandr output:

HDMI-1 connected (normal left inverted right x axis y axis)
   1680x1050     59.88 +
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
   720x400       70.08  

This shows even if monitor is not "switched off" by button. But it is not listed in the XHandle::open().unwrap().monitors(). Is it possible to list the monitors that are not "activated" somehow?

Main options datatstructures ``never freed

I looked into the libxrandr source and found a mismatch in the structure of the objects.
There is a field of XRRScreenResources that is used in XRRGetCrtcInfo(): the timestamp.

This crate therefore should also make sure that this timestamp is properly passed to the XRRGetCrtcInfo() call.
The way to do this is not throw away the raw pointer ptr in the screenresources handle and pass it into the GetCrtcInfo call, rather than allocating a new handle like I do now.

Right now the docs just contain a rough shape of how methods might be used.

Right now, the project doesn't have any sort of CI implemented.
This allowed at least one bug to pass unnoticed, which can be seen on #9, that completely broke an entire feature.

I propose the creation of a basic CI, where cargo-test, cargo-fmt and clippy are used to make sure no unwanted change goes through.

I have a semi working example of it on my fork of the repo.
Furthermore, I've found some issues while implementing this, which I'll list below, for further discussion on what should be done about this. If necessary, I'll open issues regarding each of them.

• Available tests can't be used with github actions as we don't have a monitor.
• Low test coverage.
• No guidelines to format the code. (I'm using rustfmt in my example which reformatted nearly the entire project when ran)
• Not checking whether features work before pushing them to main branch (I've used clippy both as a linter and to check whether the project's features work. Ideally this would be somewhere else, such as cargo test).

If these changes are deemed necessary by @Rintse I may continue working on my fork to at least fix the doctests then PR it here.