rust-x-bindings / rust-xcb

Rust bindings and wrapper for XCB.
MIT License
165 stars 64 forks source link

randr::ChangeOutputProperty - cannot change property to value greater than 255 #150

Closed procrastimax closed 2 years ago

procrastimax commented 2 years ago

Description

I have this function to change the backlight property of one output via the Randr feature.

I'm trying to set the backlight property with the following code:

let curr_screen_res = conn
  .wait_for_reply(conn.send_request(&randr::GetScreenResourcesCurrent {
    window: root_window,
}))?;

let curr_output = curr_screen_res.outputs()[0];

let backlight_atom = conn
  .wait_for_reply(conn.send_request(&x::InternAtom {
    only_if_exists: false,
    name: b"BACKLIGHT",
}))?;

conn.check_request(conn.send_request_checked(&randr::ChangeOutputProperty {
  output: curr_output,
  property: backlight_atom.atom(),
  mode: x::PropMode::Replace,
  data: &[255 as u32],
  r#type: x::ATOM_INTEGER,
}))?;

This works perfectly, unless I try to set a value greater than 255. If I for example set the value to 256, the backlight is set to 1. For me this indicates some kind of u8 overflow.

However the data field I set in the ChangeOutputProperty struct explicitly casts to u32.

Cargo

The xcb dependency entry in my Cargo.toml looks like this:

xcb = {version = "1.0.0-beta", features  = ["randr"] }

Observation

Setting a backlight value in the ChangeOutputProperty struct over 255, resets it to 0, i.e. 256 changes to 1.

Problem

If the fault is not on my side, then the problem seems to be that the u32 value which I want to set as the backlight value is somehow cast to a u8 value. Which then leads to an integer overflow. This could happen during the raw conversion of the struct in the generated code. I had not the time or experience to further debug the generated code (mainly the randr.rs file), to maybe find there some more information.

procrastimax commented 2 years ago

Nevermind, seems to be fixed by #149 I'm gonna test it out and maybe close this issue later :)

procrastimax commented 2 years ago

Yep, it is definitely fixed by #149! Thank you very much.