altf02 / x11-rs Goto Github PK
View Code? Open in Web Editor NEWRust bindings for X11 libraries
Home Page: https://docs.rs/x11
License: MIT License
Rust bindings for X11 libraries
Home Page: https://docs.rs/x11
License: MIT License
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 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?
See this for a rationale, basically glXGetProcAddressARB
is required by the Linux OpenGL ABI, unlike glXGetProcAddress
(which Nvidia, for instance, does not export).
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`.
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.
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.
Your CI currently only tests against nightly, and your recent 2.18.1 release has caused build failures throughout all winit PRs.
I think that the X shared memory functions (XShmGetImage and friends) are missing.
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.
Where would one find the documentation for this library?
For example my system doesn't have libXcursor.so
, instead it has libXcursor.so.1
.
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?
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 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?
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 ()
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.
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.
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).
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.
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?
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
.
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.
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)
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.
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
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 ?
The current structure of x11 and x11-dl isn't perfect. I'm considering restructuring in a later version (probably 3.0.0).
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.If this restructure happens, I'll gladly send pull requests for both servo and glutin to use the updated version.
There are some missing constants used in XRenderFindStandardFormat
:
#define PictStandardARGB32 0
#define PictStandardRGB24 1
#define PictStandardA8 2
#define PictStandardA4 3
#define PictStandardA1 4
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
CString
s so I can understand why it is this way, in retrospect.
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/?
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.
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.
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.
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.
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
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)
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!
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
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.
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
?
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.
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 use
d 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.
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.
Im not sure if this is even fixable, but compiling x11-dl takes more then one gig of ram.
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!
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)
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.