Where would one find the documentation for this library?

These are the constants I've found in my system GL/glx.h header which are not part of src/glx.rs and should be.

/*
 * Error codes returned by glXGetConfig:
 */
#define GLX_BAD_SCREEN      1
#define GLX_BAD_ATTRIBUTE   2
#define GLX_NO_EXTENSION    3
#define GLX_BAD_VISUAL      4
#define GLX_BAD_CONTEXT     5
#define GLX_BAD_VALUE           6
#define GLX_BAD_ENUM        7


/*
 * GLX 1.1 and later:
 */
#define GLX_VENDOR      1
#define GLX_VERSION     2
#define GLX_EXTENSIONS      3

// drawable type mask
#define GLX_AUX_BUFFERS_BIT     0x00000010
#define GLX_FRONT_LEFT_BUFFER_BIT   0x00000001
#define GLX_FRONT_RIGHT_BUFFER_BIT  0x00000002
#define GLX_BACK_LEFT_BUFFER_BIT    0x00000004
#define GLX_BACK_RIGHT_BUFFER_BIT   0x00000008
#define GLX_DEPTH_BUFFER_BIT        0x00000020
#define GLX_STENCIL_BUFFER_BIT      0x00000040
#define GLX_ACCUM_BUFFER_BIT        0x00000080

#define GLX_VISUAL_ID           0x800B
#define GLX_SCREEN          0x800C

#define GLX_RGBA_TYPE           0x8014
#define GLX_COLOR_INDEX_TYPE        0x8015
#define GLX_MAX_PBUFFER_WIDTH       0x8016
#define GLX_MAX_PBUFFER_HEIGHT      0x8017
#define GLX_MAX_PBUFFER_PIXELS      0x8018
#define GLX_PRESERVED_CONTENTS      0x801B
#define GLX_LARGEST_PBUFFER     0x801C
#define GLX_WIDTH           0x801D
#define GLX_HEIGHT          0x801E
#define GLX_EVENT_MASK          0x801F
#define GLX_DAMAGED         0x8020
#define GLX_SAVED           0x8021
#define GLX_WINDOW          0x8022
#define GLX_PBUFFER         0x8023
#define GLX_PBUFFER_HEIGHT              0x8040
#define GLX_PBUFFER_WIDTH               0x8041
#define GLX_PBUFFER_CLOBBER_MASK    0x08000000

/*
 * GLX 1.4 and later:
 */
#define GLX_SAMPLE_BUFFERS              0x186a0 /*100000*/
#define GLX_SAMPLES                     0x186a1 /*100001*/

I came across this while looking at how realistic it would be to merge https://github.com/servo/rust-xlib/ and x11-rs. Is there a reason to prefer this repository's glx module over https://github.com/servo/rust-glx/?

The fact that as far as I can tell, something like the below is required in order to call xlib::XCreateIC and have it work correctly is inconvenient, and took some time for me to figure out.

 xlib::XCreateIC(xw.xim,
                             CString::new(xlib::XNInputStyle).unwrap().as_ptr(),
                             xlib::XIMPreeditNothing | xlib::XIMStatusNothing,
                             CString::new(xlib::XNClientWindow).unwrap().as_ptr(),
                             xw.win,
                             CString::new(xlib::XNFocusWindow).unwrap().as_ptr(),
                             xw.win,
                             0 as *mut libc::c_void);

But after doing a bit of research, I couldn't find a nice way to do const CStrings so I can understand why it is this way, in retrospect.

I'm trying to build a simple piston project, and piston pulls x11-rs in.

When cargo gets to Compiling x11-dl v2.9.0

it fails with:

/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1849:5: 1849:11 error: macro expansion ignores token `assert` and any following
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1849     assert!(::std::mem::size_of::<XkbEvent>() >= ::std::mem::size_of::<$ty>());
                                                                                                  ^~~~~~
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1855:3: 1868:4 note: caused by the macro expansion here; the usage of `test_xkb_event_size!` is likely invalid in expression context
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1855   test_xkb_event_size! {
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1856     XkbAnyEvent,
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1857     XkbNewKeyboardNotifyEvent,
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1858     XkbMapNotifyEvent,
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1859     XkbStateNotifyEvent,
/home/letharion/.cargo/registry/src/github.com-1ecc6299db9ec823/x11-dl-2.9.0/src/xlib.rs:1860     XkbControlsNotifyEvent,

I'm a little to new to rust to work out what the issue is unfortunately. Since the code is marked as a test though, I naively tried just dropping the roughly 20 lines involved, and my project builds. (For better or worse)

xlib.rs uses the old layout from the XErrorEvent man page, which didn't match the actual layout in xlib.h until relatively recently. This leads to some fairly unhelpful error messages, because the sequence number gets substituted for the error code.

Corrected man page
xlib.h's definition

I was investigating why vdisplay was always 0 on my system.
In turns out that this library has an additional hskew field that I can't find anywhere in any reference. This seems wrong.

I use this in my code, and I think it would be a great addition to the library:

fn cast_event<T: From<xlib::XEvent>>(ev: &xlib::XEvent) -> &T
{
    unsafe { mem::transmute(ev) }
}

it should be safe because the size of XEvent is >= the size of T (tested elsewhere). Using From<XEvent> does an unnecessary copy and this provides an alternative.

Im not sure if this is even fixable, but compiling x11-dl takes more then one gig of ram.

Hi there!

Are you able to push a new crate version which includes a0e55af?

Thanks!

LTS distros such as ubuntu 14.04 don't have an easy way to run libXrandr 1.5 on their system. Linking x11-dl's xrandr module fails on such systems. I'm not sure of a great solution to support both versions. One option would be feature flags, but that gets cumbersome as the number of releases increases. Custom attributes could be used on nightly (eg #[xrandr(1.5)]), but that's not a very general solution. A third option would be splitting this into several repos which could track their libX_whatever_ directly. Admittedly, none of these solutions are great. In the mean time, I'm using a fork which drops monitor support to work with 1.4.2.

I have a few issues with the way these crates are structured.

(1) x11 and x11-dl both expose their own copies of all native types and constants. This is currently done using symlinks to the source files, but it would be much nicer to just include the types in one crate (x11) and have others (x11-dl) depend on this crate for its types and constants (but of course without the need to statically link any C libraries to use these types). If backwards compatibility is desired, these types and constants can be pub used into x11-dl, but I don't think this is the best thing to do. This and the next problem would likely entail a version bump to 3.0.0...

(2) Everything currently lies within public submodules within the main crate(s). For example, one of the most commonly used types is x11::xlib::Display/x11_dl::xlib::Display. In addition to moving types into one crate, I believe these should be exposed to the root of the crate (i.e. x11::Display). They're currently lumped into modules somewhat arbitrarily, based only on what X library they seem to be most relevant to. If we move everything into the crate root, it will (a) be easier to find and reference these types and (b) be easier to transition to bindings generated from the C headers if desired.

Hi
Thank you for your nice cargo.

I tried to use x11-rs in my cargo project.
However, I got errors below

   Compiling libc v0.2.13
   Compiling pkg-config v0.3.8
   Compiling x11 v2.6.1
   Compiling sample_x11 v0.1.0 (file:///home/mopp/Workspace/repo/sample_x11)
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/mopp/Workspace/repo/sample_x11/target/debug/sample_x11.0.o" "-o" "/home/mopp/Workspace/repo/sample_x11/target/debug/sample_x11" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/mopp/Workspace/repo/sample_x11/target/debug" "-L" "/home/mopp/Workspace/repo/sample_x11/target/debug/deps" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/mopp/Workspace/repo/sample_x11/target/debug/deps/libx11-0c02163178e7e983.rlib" "/home/mopp/Workspace/repo/sample_x11/target/debug/deps/liblibc-30d46fdd62f8c2eb.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-fe3cdf61.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-fe3cdf61.rlib" "-l" "util" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
note: /home/mopp/Workspace/repo/sample_x11/target/debug/sample_x11.0.o: In function `sample_x11::main':
/home/mopp/Workspace/repo/sample_x11/src/main.rs:11: undefined reference to `XOpenDisplay'
collect2: error: ld returned 1 exit status

error: aborting due to previous error
error: Could not compile `sample_x11`.

It could not find xlib.
But, libX11 is installed already, and I can build and run your examples in the repo.
Maybe, I made some mistakes in my environment (Arch Linux).
How can I solve this problem ?

Thanks

Your CI currently only tests against nightly, and your recent 2.18.1 release has caused build failures throughout all winit PRs.

https://travis-ci.org/tomaka/winit/jobs/407823862#L764

This is easily one of the most useful snippets of code I've seen recently. I copy-pasted it into udev-dl where I needed it, but it'd be neat if it was in its own crate!

The README currently specifies this as being released under public domain, which can lead to issues in some countries (including the US, where I am). I'm proposing that we release this under MIT instead, as this is the license used by the X11 libraries that are wrapped by this project. Please reply with "yes" if you agree to this change. If I get a "yes" from most contributors but not all, I'll rewrite any remaining contributions myself before pushing this change.

Edit: The main concern is that "public domain" does not provide the protection of a warrantly clause. I don't know of a particular time that this has been a problem, but it's better to be safe.

* [x] @Daggerbot
* [x] @meh
* [ ] @darkstalker
* [x] @alxkolm
* [ ] @mason-larobina
* [x] @SimonSapin
* [x] @jespino
* [x] @francesca64
* [x] @bennofs
* [x] @sleeparrow
* [x] @crumblingstatue
* [x] @Eijebong
* [x] @nox
* [x] @arielb1
* [x] @EPashkin
* [x] @mgsloan
* [x] @joshtriplett
* [x] @myfreeweb
* [x] @nicokoch
* [x] @mbrubeck
* [x] @jdm
* [ ] @wartman4404
* [ ] @aweinstock314
* [ ] @BOTBrad

Hey,

I’d be interested in using this library, but I need the no_std support. Do you have anything for this? Would you accept a patch for it (if it’s easy)? Otherwise, I’ll just wrap my own functions in my (very specific) code, but if others are interested…

Kudos for the good work!

The various Xkb* events and flags don't seem to be bound. These are needed for reliable keyboard handling with xkbcommon-x11. It's easy to work around this by defining whatever you need locally and using transmute, but that leads to duplication of effort. The planned move to autogenerated bindings (#40) should fix this, but I thought I'd make a note anyway.

I ran valgrind on some code I had written and found that some memory isn't deallocated on close. This probably doesn't matter unless you keep closing/opening the X lib a LOT, but it's nice to tidy up after ourselves ;). I used x11_dl, haven't checked x11.

Of course it might be a leak in X, or some mem that can only be allocated once, in which case it doesn't matter.

==4119== Memcheck, a memory error detector
==4119== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4119== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4119== Command: ./target/debug/main
==4119== 
==4119== 
==4119== HEAP SUMMARY:
==4119==     in use at exit: 32 bytes in 1 blocks
==4119==   total heap usage: 136 allocs, 135 frees, 83,124 bytes allocated
==4119== 
==4119== 32 bytes in 1 blocks are still reachable in loss record 1 of 1
==4119==    at 0x4C2EF35: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4119==    by 0x4E3A63B: ??? (in /usr/lib/libdl-2.26.so)
==4119==    by 0x4E39F21: dlopen (in /usr/lib/libdl-2.26.so)
==4119==    by 0x148E98: x11_dl::link::DynamicLibrary::open (link.rs:90)
==4119==    by 0x149391: x11_dl::link::DynamicLibrary::open_multi (link.rs:119)
==4119==    by 0x14A6C6: x11_dl::xlib::Xlib::open (link.rs:57)
==4119==    by 0x11C1A8: main::run (main.rs:7)
==4119==    by 0x11CBB6: main::main (<quick_main macros>:4)
==4119==    by 0x17E6DC: __rust_maybe_catch_panic (lib.rs:99)
==4119==    by 0x17811B: try<(),closure> (panicking.rs:459)
==4119==    by 0x17811B: catch_unwind<closure,()> (panic.rs:361)
==4119==    by 0x17811B: std::rt::lang_start (rt.rs:59)
==4119== 
==4119== LEAK SUMMARY:
==4119==    definitely lost: 0 bytes in 0 blocks
==4119==    indirectly lost: 0 bytes in 0 blocks
==4119==      possibly lost: 0 bytes in 0 blocks
==4119==    still reachable: 32 bytes in 1 blocks
==4119==         suppressed: 0 bytes in 0 blocks
==4119== 
==4119== For counts of detected and suppressed errors, rerun with: -v
==4119== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

I am struggling to bring in all the x libs needed to make winit work, and I am stuck on xlib_xcb. I suspect I actually have all the libs, but I just don't have /usr/lib/pkgconfig/xlib_xcb.pc. That .pc file does not appear to exist in the xorg sources, so I am wondering if something os-specific is happening here. Which Linux's are known to work well so I can direct my investigation better?

I've tried both NixOs and Gentoo. Both fail to provide an xlib_xcb.pc from libX11 and libxcb.

Currently xkb and xcms are submodules of xlib because their functions are found in libX11.so. Should I move them up to the library root beside xcursor and xf86vmode?

These are the "back"/"forward" buttons on newer keyboards, often part of the arrow keypad. They have keycodes of 0x1008ff26 and 0x1008ff27 and are called XF86Back and XF86Forward respectively.

Filing an issue since I'm not sure if x11-rs wants to have such keys.

I ran into this when trying to run my own build of alacritty. I verified that my /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0 does not export XRRChangeProviderProperty.

thread 'main' panicked at 'Failed to initialize any backend!
    Wayland status: NoWaylandLib
    X11 status: LibraryOpenError(
    OpenError {
        kind: Symbol,
        detail: "XRRChangeProviderProperty - /usr/lib/x86_64-linux-gnu/libXrandr.so.2.2.0: undefined symbol: XRRChangeProviderProperty"
    }
)
', /opt/rust/.cargo.Linux/registry/src/github.com-1ecc6299db9ec823/winit-0.15.0/src/platform/linux/mod.rs:418:9
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::panicking::default_hook::{{closure}}
             at libstd/sys_common/backtrace.rs:71
   2: std::panicking::rust_panic_with_hook
             at libstd/panicking.rs:227
             at libstd/panicking.rs:463
   3: std::panicking::begin_panic
             at /checkout/src/libstd/panicking.rs:397
   4: alacritty::display::Display::new
             at /opt/rust/.cargo.Linux/registry/src/github.com-1ecc6299db9ec823/winit-0.15.0/src/platform/linux/mod.rs:418
   5: alacritty::main
             at src/main.rs:104
             at src/main.rs:62
   6: std::rt::lang_start::{{closure}}
             at /checkout/src/libstd/rt.rs:74
   7: main
   8: __libc_start_main
   9: <unknown>

Can this symbol being missing be marked as non-fatal somehow?

I am confused with the definition of Atom (and friends) in xlib.rs. The X protocol specification says it should be a 32 bit value. That is how it is defined in Xproto.h for me:

#define Atom CARD32

On my 64 bit machine, c_ulong ends up as a u64. Can anyone shed some light on this?

I am attempting to make a function that get the resolution and refresh rate of the monitor(only figured out resolution so far) and I can only compile it atm by running the function in its on project and building it with cargo rustc -- -lX11

My Code

use std::ptr;
use x11::xlib::{XCloseDisplay, XOpenDisplay, XScreenCount, XScreenOfDisplay};

pub fn resolution() {
    unsafe {
        // open a display
        let display = XOpenDisplay(ptr::null());
        // return the number of available screens
        let count_screens = XScreenCount(display);

        println!("Number of screens: {}", count_screens);
        for i in 0..count_screens {
            let screen = *XScreenOfDisplay(display, i);
            println!("\tScreen {}: {}x{}", i + 1, screen.width, screen.height);
        }
        // close the display
        XCloseDisplay(display);
    }
}

pub fn main() {
    resolution();
}

This my Cargo.toml

[package]
edition = "2018"
 
[dependencies]
libc = "0.2"
x11 = "2.18.1"

Am I doing something wrong? Is there anyway I can run this from with a project with multiple file inside the src directory?

Do you plan add X Record Extension bindings?

get_short, get_long, set_short and set_long all point to the first element regardless of the value of index. I'll fix as soon as i get home.

The current structure of x11 and x11-dl isn't perfect. I'm considering restructuring in a later version (probably 3.0.0).

1. In order to make the switch quick and easy, we can probably glob re-export everything into the top module in both crates.
2. Originally, all symbols were organized by the shared object that they are most relevant to, but xrecord was split from xtest, and xinput2 was split from xinput. We can use bindgen to generate types and constants based on the header file that they're defined in. This won't work as well for functions, as functions from the same library are often declared in different headers. So I suggest that each shared object will also have its own source file.
3. Another big change is that x11-dl should use the types and constants defined in x11, rather than redefining them. It's possible for large projects to build both x11 and x11-dl due to their dependency trees, so this could prevent potential clashes.
4. Compile times in x11-dl are very long. Using cargo features to build only the libraries that are needed is partial solution. Otherwise, compile times will only get worse as more libraries are added to the crate.

If this restructure happens, I'll gladly send pull requests for both servo and glutin to use the updated version.

For example my system doesn't have libXcursor.so, instead it has libXcursor.so.1.

Most structs in the library should derive Debug, since they're plain data.
Also once #68 is merged, it should be possible to manuall implement Debug for XEvent.

Seem to only appear when xtest::XTestFakeKeyEvent is in the code. xtest::XTestFakeButtonEvent works fine.

/home/mikhail/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_uni
code-cfbd6648f7db2ee5.rlib" "/home/mikhail/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unk
nown-linux-gnu/lib/libcore-687e6a964d22cbb4.rlib" "/home/mikhail/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/
lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-987729be881d4d32.rlib" "-Wl,-Bdynamic" "-l" "X11" "-l"
 "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-
l" "util"
  = note: /home/mikhail/Documents/InputBot/target/debug/deps/libinputbot-17f3ee6752fe300d.rlib(inputbot-17f3ee6752fe
300d.0.o): In function `inputbot::linux::send_keybd_input':
          /home/mikhail/Documents/InputBot/src/linux/mod.rs:85: undefined reference to `XTestFakeKeyEvent'
          collect2: error: ld returned 1 exit status


error: aborting due to previous error

error: Could not compile `inputbot`.

Edit (20 October 2016): I'm working on a generator using clang. There will be a major restructure. The x11 crate will have function bindings moved into a separate crate called x11-static while x11 will only contain only types and constants (similar to the winapi crate). Both x11-static and x11-dl will depend on x11 for these items so there will no longer be duplicates. x11-generator will be a build dependency to generate the function bindings and will be available for custom bindings as well.

x11 and x11-generator will be built using x11-parser, which scans the C headers to generate bindings. The code generated by x11-parser will be commited to the repository, so the C headers won't have to be present when building the Rust bindings.

I am considering changing x11-dl to use lazy initialization. This will prevent the loader functions from failing if there are missing functions in order to avoid versioned structs. Instead, calling a missing function will cause a panic.

Note: Version 3 probably won't be stable until untagged unions are a stable feature in Rust.

Glutin is soon getting support for Wayland, and as a such there is a small problem: Wayland users don't necessarly have X11 installed.

For this reason, I wanted to do what the SDL already does: dlopen the xlib library at runtime and load the symbols from it, instead of just linking with an extern block.

I have already been experimenting with a library named shared_library that would make this process easier, but I wanted to know if you would agree with this change first. If you do, I'll make the changes and open a PR.

(the same question applies for osmesa, but opening two separate issues would be overkill)

Cross-posting from rust-lang

rust-lang/rust#52875 (comment)

Cargo.toml:x11-dl = "2.18.1"
Illegal instruction with Rust nightly

2018-07-30T20:46:20.443731114+01:00 INFO rust_oids::app - Resuming simulation from snapshot: "/home/nico/.config/rust-oids/saved_state/20180730_193912.json"
error: XDG_RUNTIME_DIR not set in the environment.
Illegal instruction
nico@lenovo-devuan:~/Projects/itadinanta/rust-oids$ gdb target/release/rust-oids 
GNU gdb (Debian 7.12-6+b2) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from target/release/rust-oids...done.
(gdb) run
Starting program: /u01/home/nico/Projects/itadinanta/rust-oids/target/release/rust-oids 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
2018-07-30T20:46:43.747665697+01:00 INFO rust_oids::app - Resuming simulation from snapshot: "/home/nico/.config/rust-oids/saved_state/20180730_193912.json"
error: XDG_RUNTIME_DIR not set in the environment.

Program received signal SIGILL, Illegal instruction.
0x0000555555758d1b in x11_dl::xlib_xcb::Xlib_xcb::open::hcf5d0b06fb3c742a ()
(gdb) stack
Undefined command: "stack".  Try "help".
(gdb) help
List of classes of commands:

aliases -- Aliases of other commands
breakpoints -- Making program stop at certain points
data -- Examining data
files -- Specifying and examining files
internals -- Maintenance commands
obscure -- Obscure features
running -- Running the program
stack -- Examining the stack
status -- Status inquiries
support -- Support facilities
tracepoints -- Tracing of program execution without stopping the program
user-defined -- User-defined commands

Type "help" followed by a class name for a list of commands in that class.
Type "help all" for the list of all commands.
Type "help" followed by command name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) bt
#0  0x0000555555758d1b in x11_dl::xlib_xcb::Xlib_xcb::open::hcf5d0b06fb3c742a ()
#1  0x00005555556f9b20 in winit::platform::platform::x11::xdisplay::XConnection::new::hd8037cc51043bb68 ()
#2  0x00005555556f14bc in std::sync::once::Once::call_once::_$u7b$$u7b$closure$u7d$$u7d$::h3db9c6506b2778f4 ()
#3  0x00005555557f70e1 in std::sync::once::Once::call_inner::h19d8fb8519a6ca98 () at libstd/sync/once.rs:349
#4  0x0000555555702945 in winit::platform::platform::EventsLoop::new::h96a6247628a19d25 ()
#5  0x00005555556fe0b8 in winit::EventsLoop::new::h494bdedfa0de9eda ()
#6  0x000055555565b8c0 in rust_oids::app::main::main_loop::h05b6ab6851b78251 ()
#7  0x00005555555f3645 in rust_oids::app::run::h9bd1da782e5bcfa7 ()
#8  0x00005555556390f6 in rust_oids::main::h93ddf1c0aa5bdd7c ()
#9  0x0000555555625c23 in std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h8a490e39f0d9316a ()
#10 0x00005555557e4ff3 in std::rt::lang_start_internal::_$u7b$$u7b$closure$u7d$$u7d$::he46bbe21d122334d () at libstd/rt.rs:59
#11 std::panicking::try::do_call::h8ed5eafe3e94e158 () at libstd/panicking.rs:310
#12 0x000055555580492a in __rust_maybe_catch_panic () at libpanic_unwind/lib.rs:105
#13 0x00005555557e7a16 in std::panicking::try::hb8f13a044e539797 () at libstd/panicking.rs:289
#14 std::panic::catch_unwind::h09594af9f6e0fec4 () at libstd/panic.rs:392
#15 std::rt::lang_start_internal::ha4a5edbf3a495792 () at libstd/rt.rs:58
#16 0x0000555555639c04 in main ()

There are some missing constants used in XRenderFindStandardFormat:

#define PictStandardARGB32  0
#define PictStandardRGB24   1
#define PictStandardA8	    2
#define PictStandardA4	    3
#define PictStandardA1	    4

See servo/servo#6483 for an example of what happens if you don't.

If a person attempts to build without the deps installed, it unselects the feature and compiles anyway, and then you get weird link omissions later on.

cc @alexcrichton

When gl_generator's StructGenerator attempts to load a missing function, it doesn't fail like x11-dl currently does. Instead, it replaces the function with a panic wrapper with the same signature. This way a single missing function doesn't prevent the entire library from loading. I propose that we do the same thing in x11-dl. This would make the Xrandr_2_2_0 struct in old_xrandr.rs obsolete, and it would prevent similar situations from happening in the future (whether they're likely to happen or not). In addition, a function can be added to check by name whether a symbol is available. If desired, I may have time to implement this some time in the next week.

Background: x11-dl structures represent the public symbols exported by a shared object (like XOpenDisplay from libX11.so.6 in a struct called Xlib). If the library on the user's machine is missing even one of these symbols, the entire struct completely fails to initialize. IIRC, this happened on debian sid, making x11-dl completely unusable on such systems.

See https://travis-ci.org/servo/rust-azure/builds/192097103 (servo/rust-azure#253).

Concretely, the error is "Requested 'x11 >= 1.6' but version of X11 is 1.4.99.1". This used to work, so I guess it's safe to downgrade the minimum required version?

The XRender constants aren't defined in the x11::xrender module. Those correspond to the defines in /usr/include/X11/extensions/render.h, everything but the X_* things (the protocol stuff).

One of the essential tasks for setting up XInput is enabling delivery of events that the program is interested in. This is done with several XI*Mask() functions which are defined as macros in XI2.h.

These could be translated to simple rust functions and added to xinput.rs but before doing that, I wanted to check how the bindings are generated in the first place and whether there were any automatic tools for doing this?

/* XI2 event mask macros */
#define XISetMask(ptr, event)   (((unsigned char*)(ptr))[(event)>>3] |=  (1 << ((event) & 7)))
#define XIClearMask(ptr, event) (((unsigned char*)(ptr))[(event)>>3] &= ~(1 << ((event) & 7)))
#define XIMaskIsSet(ptr, event) (((unsigned char*)(ptr))[(event)>>3] &   (1 << ((event) & 7)))
#define XIMaskLen(event)        (((event) >> 3) + 1)

I'd like to deprecate the x11-dl crate in favor of safe bindings (keeping x11 available where it's a better fit). I'm undecided on whether low- or high-level safe bindings would be better. By low-level, I mean a safe library that doesn't do much more than speak the X11 protocol (similar to XCB), while a high-level binding would use RAII structs to represent resources. For example:

// Low-level, safe binding
let display = x11::Display::open_default().unwrap();
let window: u32 = display.create_window(..........);
display.map_window(window);
.......... // main loop
display.unmap_window(window);
display.destroy_window(window);

And...

// High-level, safe binding
let display = x11::Display::open_default().unwrap();
let window: x11::Window = display.create_window(..........);
window.map();
.......... // main loop
window.unmap();

I've played around with code that uses the low-level approach of providing a Display struct that speaks the X protocol alone. It uses XOpenDisplay to connect to the display but otherwise uses XCB anywhere possible. The prime example of where XCB can't used afaik is when working with GLX contexts, so libX11 can't be eliminated entirely. The bindings would attempt to be neutral to Xlib and XCB but prefer the XCB way of doing things when there is a conflict.

@tomaka The major projects using x11-dl that I'm aware of are glutin and winit, so what do you think? Do you prefer high-level, low-level, or keep x11-dl the way it is? I'm leaning toward low-level, as high-level would almost result in a winit-like API but not cross-platform. If I get around to making this new crate, I can update glutin and winit to utilize it. However, I'm mostly just brainstorming ideas and this would likely not be any time soon, as I'm busy with school these days.

@francesca64 (replying to your comment in #82)

EDIT: A third alternative that would keep x11-dl mostly as it is while somewhat preventing problems like #81 would be to either return library structs successfully even with missing symbols returned as null, or to wrap functions in Option. Both of these would be pretty cumbersome to work with and the bindings would still be unsafe, but this would take the least work to implement.

I think that the X shared memory functions (XShmGetImage and friends) are missing.

I'm trying to assign _NET_WM_WINDOW_TYPE for my window to be _NET_WM_WINDOW_TYPE_DESKTOP, but it segfaults in the XChangeProperty function.

My code:

let window_type_str = CString::new("_NET_WM_WINDOW_TYPE").unwrap();
let window_type_desktop_str = CString::new("_NET_WM_WINDOW_TYPE_DESKTOP").unwrap();

let window_type = (x_connection.xlib.XInternAtom)(x_display, window_type_str.as_ptr(), 0);
let window_type_desktop = (x_connection.xlib.XInternAtom)(x_display, window_type_desktop_str.as_ptr(), 0);

(x_connection.xlib.XChangeProperty)(x_display, x_window, window_type, XA_ATOM, 32, PropModeReplace, window_type_desktop as *const u8, 1);

And the gdb backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x00007f5b970edc40 in _XData32 () from /usr/lib/libX11.so.6
#0  0x00007f5b970edc40 in _XData32 () from /usr/lib/libX11.so.6
#1  0x00007f5b970c8683 in XChangeProperty () from /usr/lib/libX11.so.6
#2  0x00000001000ae4e0 in yotredash::desktop_window (display=0x7fffffffd868) at src/main.rs:170
#3  0x00000001000ae793 in yotredash::init_display (args=0x7fffffffda98) at src/main.rs:194
#4  0x00000001000af99a in yotredash::main () at src/main.rs:269

The pointers come from glutin, if that makes any difference at all

I'm porting some C code to Rust and I just had to dig these values out of X11/Xutil.h in order to move the part that interpreted the result of XParseGeometry into Rust.

/*
 * Bitmask returned by XParseGeometry().  Each bit tells if the corresponding
 * value (x, y, width, height) was found in the parsed string.
 */
#define NoValue		0x0000
#define XValue  	0x0001
#define YValue		0x0002
#define WidthValue  	0x0004
#define HeightValue  	0x0008
#define AllValues 	0x000F
#define XNegative 	0x0010
#define YNegative 	0x0020 

It would be nice if these values were available through this crate.

I'm porting some code from C to Rust, and it is frequently using None to compare against Window or Atom. In the X11/X.h None is defined to be 0 by preprocessor macro. Currently i compare values against 0, but that doesn't seem like a good idea. What is the reason behind None not being in the API ?

Greetings,

As far as I see it, making most structs derive at least Debug would be super convenient while not harmful. For instance, when drafting an error handler, it would be really nice to be able to format the XErrorEvent struct in a single line, but as of today I can't, and I have to log each field manually instead.

So I wonder if there's anything I'm missing and would really appreciate if this was "fixed". I would make a PR but I'd like to ensure that it's fine to do first.

All rights reserved is quite strong. Can I suggest you use the MIT License, or better yet the CC0 License? The CC0 is very appropriate for glue-code.

I'm trying to use XUniqueContext with this binding library (all good work).

I tried to add it myself to x11/xlib.rs but linking fails with undefined reference to XUniqueContext. I'm guessing that since this occurs at the linking stage, that XUniqueContext is not defined in libX11.so.

Why, I wonder? I'd really love to use it.

Thanks.

See this for a rationale, basically glXGetProcAddressARB is required by the Linux OpenGL ABI, unlike glXGetProcAddress (which Nvidia, for instance, does not export).