events, mouse button 2 possible bug?
Hello, I am new to xlib/xcb and started off (not knowing any better) with gdk/gtk3. So created the event loop but in the handling of events I came upon an oddity. I wrote xcb, no response, so assume this is a bug because of response. The event sequence for button 2 mouse press: window 83886080, LEAVE_NOTIFY (623,112) window 83886080, ENTER_NOTIFY (623,112) window 83886080, BUTTON_PRESS Button 2 modifier 0 (623,112) An assumption would be if this is in fact a feature of button 2, that it is to signal a drag begin event. But that seemed a little illogical to me. I would think that to be something like: window 83886080, BUTTON_PRESS Button 2 modifier 0 (623,112) window 83886080, LEAVE_NOTIFY (623,112) window 83886080, ENTER_NOTIFY (623,112) or BUTTON_PRESS, FOCUS_OUT, FOCUS_IN. If is a feature, can someone please (as simplistically as possible) explain how to use. If not a feature, what is best way to block/ignore so as not to run extra code that may be attached to handling event LEAVE_NOTIFY of a button press event. Steve
Re: events, mouse button 2 possible bug?
On Wed, Jul 10 2024 at 02:10:15 PM +, Julian Bradfield
wrote:
You haven't given anything like enough information. However, what I
suspect this means is that some other client, such as a window
manager, has a passive grab on the button, so when you pressed the
button, the other client grabbed it (causing a LeaveNotify to your
client), and then released the grab (causing the EnterNotify) and
passed the ButtonPress on to your client.
I'll buy the window manager! Just to be sure though, could you please
try attached. It's a quickly butchered base of what I have. When over
window, just use button 2.
Created/run by:
gcc -g basic.c -lxcb && ./a.out
And thank you for a response and that bit of help!
And if window manager, I guess nothing to be done but let it ride :(
Steve
#include
#include
#include
#include
#include
#include
#include
typedef struct { int16_t x, y, w, h; } PhxRectangle;
#define DEBUG_EVENTS 1
static char *
_xkey_names(xcb_keysym_t sym) {
(void)sym;
return "XK_Return";
}
static xcb_keysym_t
_xcb_keysym_for(xcb_keycode_t keycode, uint16_t modifiers) {
(void)keycode;
(void)modifiers;
return 0x0ff0d;
}
static void
xcb_main(xcb_connection_t *connection, xcb_window_t window) {
#if DEBUG_EVENTS
puts("XCB_PROP_MODE_REPLACE");
#endif
/* code to allow delete window instead of quit */
xcb_intern_atom_cookie_t cookie
= xcb_intern_atom(connection, 1, 12, "WM_PROTOCOLS");
xcb_intern_atom_reply_t *reply
= xcb_intern_atom_reply(connection, cookie, 0);
xcb_intern_atom_cookie_t cookie2
= xcb_intern_atom(connection, 0, 16, "WM_DELETE_WINDOW");
/* reply2 needs retension for XCB_CLIENT_MESSAGE */
xcb_intern_atom_reply_t* reply2
= xcb_intern_atom_reply(connection, cookie2, 0);
xcb_change_property(connection, XCB_PROP_MODE_REPLACE,
window,
(*reply).atom, XCB_ATOM_ATOM, 32, 1, &(*reply2).atom);
/* set all before through to Xserver */
xcb_flush(connection);
/* setting of window per user's request */
_Bool once = true;
/* set to false after all windows closed */
_Bool run_loop = true;
xcb_generic_event_t *event;
while ( run_loop && (event = xcb_wait_for_event(connection)) ) {
switch (event->response_type & ~0x80) {
case XCB_KEY_PRESS: { /* response_type 2 */
xcb_key_press_event_t *kp = (xcb_key_press_event_t*)event;
xcb_keysym_t keyval = _xcb_keysym_for(kp->detail, kp->state);
#if DEBUG_EVENTS
printf("window %"PRIu32" KEY_PRESS"
" code %"PRIu8" modifers %"PRIu16""
" keyval %"PRIx32" key_name %s\n",
kp->event, kp->detail, kp->state, keyval, _xkey_names(keyval));
#endif
break;
}
case XCB_KEY_RELEASE: { /* response_type 3 */
xcb_key_release_event_t *kr = (xcb_key_release_event_t*)event;
xcb_keysym_t keyval = _xcb_keysym_for(kr->detail, kr->state);
#if DEBUG_EVENTS
printf("window %"PRIu32" KEY_RELEASE"
" code %"PRIu8" modifers %"PRIu16""
" keyval %"PRIx32" key_name %s\n",
kr->event, kr->detail, kr->state, keyval, _xkey_names(keyval));
#endif
break;
}
case XCB_BUTTON_PRESS: { /* response_type 4 */
xcb_button_press_event_t *bp = (xcb_button_press_event_t*)event;
#if DEBUG_EVENTS
switch (bp->detail) {
case 4:
printf("window %"PRIu32", BUTTON_PRESS Wheel Scroll up"
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
bp->event, bp->state, bp->event_x, bp->event_y);
break;
case 5:
printf("window %"PRIu32", BUTTON_PRESS Wheel Scroll down"
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
bp->event, bp->state, bp->event_x, bp->event_y);
break;
case 6:
printf("window %"PRIu32", BUTTON_PRESS Wheel Scroll left"
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
bp->event, bp->state, bp->event_x, bp->event_y);
break;
case 7:
printf("window %"PRIu32", BUTTON_PRESS Wheel Scroll right"
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
bp->event, bp->state, bp->event_x, bp->event_y);
break;
default:
printf("window %"PRIu32", BUTTON_PRESS Button %"PRIu8""
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
bp->event, bp->detail, bp->state, bp->event_x, bp->event_y);
break;
}
#endif
break;
}
case XCB_BUTTON_RELEASE: { /* response_type 5 */
xcb_button_release_event_t *br = (xcb_button_release_event_t*)event;
#if DEBUG_EVENTS
printf("window %"PRIu32", BUTTON_RELEASE Button %"PRIu8""
" modifier %"PRIu16" (%"PRIi16",%"PRIi16")\n",
br->event, br->detail, br->state, br->ev
Re: events, mouse button 2 possible bug?
On Wed, Jul 10 2024 at 04:06:51 PM +, Julian Bradfield wrote: as expected. Thank you for your time! After you said window manager, gears turned. I ran a test on a notebook, simulated but creates button 2 event, and another OS on this computer. I got the same results as you. So definitely this window manager I'm on. Thank you! Thank you! Steve
Re: scroll lock disabled by default
Just so you know someone read you, I'll take a stab at the question. Mind you I haven't used Windows since Windows 3. If I had to guess, Windows doesn't have Scroll Lock on by default. I believe arrow keys still work. After the purchase of Excel, they continued the old IBM of utilizing the function key for it. I'd guess there might even be a preference setting in all 'Office' suites to not enable it 'on' by default. That said, 'function' keys aren't activated by default, nor should extra function keys "PRTSCR, SCRLCK, PAUSE". Additionally, as OSs evolved, mice ended up with scroll wheels making the old IBM key near useless, or unneeded. Windows heavily depends on it's office suites, so unless its broke, don't get rid of tradition. Other programs like Calc, LibreOffice, etc need to emulate what people are accustom to. Honestly, I'd be pissed if I had to find the scroll lock just to use arrow keys. Hope this helps, and check with the programs for the preference setting. Steve
Re: Issue Accessing Kali Linux – Blue Screen on Boot
On Wed, Apr 16 2025 at 06:30:46 PM +, Drake Derek wrote: it gets stuck on a blue screen and does not proceed to the desktop environment I'm not an x.org expert, but my first question is if blue screen, are you overclocking or is your ram in correct slot? I got that condition on very cold mornings and was solved by altering an overclocked value to compensate temperature. Steve
xf86-video amd
Just built a X Server and trying to configure. Needed raw building/testing environment for dealing with window managers' interloping. Unfortunately I can't find info or way to resolve my question so... on an AMD 2400g Raven Ridge, to firmware "Raven", I wish to verify my Xorg.0.log is correct. On a debian/ubuntu based OS, PearlOS, data is: AMDGPU(0): glamor X acceleration enabled on AMD Radeon Vega 11 Graphics (raven, LLVM 15.0.7, DRM 3.42, 5.15.0-138-generic) On new build: modeset(0): glamor X acceleration enabled on AMD Radeon Vega 11 Graphics (radeonsi, raven, LLVM 19.1.7, DRM 3.60, 6.13.4) Basically both logs the same except one uses 'AMDGPU' the other 'modeset'. The modeset outputs more info where the other is more direct, which is fine :) Now the question: will the new build be capable of Vulkan? Information suggests no if it's using the ATI driver versus the AMDGPU driver. I assume modeset is handling this but don't know. Mesa was built with Vulkan, assuming I did that correctly. Steve
Re: Segmentation Fault vmware / vgahw
On Thu, May 22 2025 at 07:18:02 PM +, Doug Kehn wrote: [34.672] (EE) Failed to load module "fbdev" (module does not exist, 0) Spitballing it but maybe check with VMWare and see if you need drivers from https://www.x.org/archive//individual/driver/ like maybe the nouveau or fbdev of the xf86-video drivers. Again, I'm no expert, but maybe a direction?
Re: Segmentation Fault vmware / vgahw
On Thu, May 22 2025 at 07:18:02 PM +, Doug Kehn wrote: Current Operating System: Linux archlinux-DESKTOP-IPGM1GV 6.14.6 Not an expert, but by any chance your video is AMD? I had recent issue with kernels greater or equal to 6.3. It wasn't the "fbdev" but started there. Failed to start was kinda the issue in that I couldn't see output but could run. Could read logs with semi-similar output.
Re: Segmentation Fault vmware / vgahw
On Thu, May 22 2025 at 10:53:23 PM +, Doug Kehn wrote: It's NVIDIA. Then not the AMD driver issue :)
Re: Move a window
For any attempting to help, God bless and here's version 2. It adds
define switches to allow override-redirect (killing of them messing
with configure), a per_icccm, and a compiz switch (ability to use
EWMH). Other property attempts not included for fear of getting too
messy. Using override is close to what wanted, but negates features
window managers provide, like graphics, virtual desktop switching
(which is great for non-compliant anyways). Objective is after-all to
create headerbars, but receive full wm support, like real configure
notices.
The compiz switch can be tried on other non-gnome type managers, it may
work? It's from the EWMH protocols.
Steve
/*
* Move window demo
* Steven J Abner 2025
*/
#include
#include
#include
#include
#include
#include
#include
#include
#define OVERRIDE 1
#define PER_ICCCM 0
#if PER_ICCCM
#undef OVERRIDE
#define OVERRIDE 0
#endif
#define USING_COMPIZ 0
#if USING_COMPIZ
#undef OVERRIDE
#define OVERRIDE 0
#undef PER_ICCCM
#define PER_ICCCM 0
#endif
/* gcc -ansi -pedantic -Wall -g -o xmove xmove.c -lxcb */
typedef struct _PhxInterface PhxInterface;
typedef struct _PhxRectangle { int16_t x, y, w, h; } PhxRectangle;
xcb_connection_t *connection = NULL;
xcb_atom_t WM_PROTOCOLS;
xcb_atom_t WM_DELETE_WINDOW;
int16_t xroot, yroot;
struct _PhxInterface {
PhxRectangle mete_box;
xcb_window_t window;
} iface0 = { {0}, 0 };
#if (__STDC_VERSION__ <= 199901L)
#define RECTANGLE(a,b,c,d,e) \
a.x = b, a.y = c, a.w = d, a.h = e
#else
#define RECTANGLE(a,b,c,d,e) \
a = (PhxRectangle){ b, c, d, e }
#endif
static bool
event_keyboard(xcb_generic_event_t *nvt) {
xcb_key_press_event_t *kp = (xcb_key_press_event_t*)nvt;
xcb_client_message_event_t *message;
message = calloc(32, 1);
message->response_type = XCB_CLIENT_MESSAGE;
message->format = 32;
message->window = kp->event;
message->type = WM_PROTOCOLS;
message->data.data32[0] = WM_DELETE_WINDOW;
message->data.data32[1] = kp->time;
xcb_send_event(connection, false, message->window,
XCB_EVENT_MASK_NO_EVENT, (char*)message);
xcb_flush(connection);
return true;
}
#if (!USING_COMPIZ)
static bool
event_mouse(xcb_generic_event_t *nvt) {
bool locus = ((nvt->response_type & (uint8_t)~0x80) == XCB_BUTTON_PRESS);
xcb_button_press_event_t *mouse
= (xcb_button_press_event_t*)nvt;
if (locus) {
xcb_grab_pointer_cookie_t c0;
xcb_grab_pointer_reply_t *r0;
xroot = mouse->root_x;
yroot = mouse->root_y;
c0 = xcb_grab_pointer(connection, 1, mouse->event,
XCB_EVENT_MASK_BUTTON_PRESS | XCB_EVENT_MASK_BUTTON_RELEASE
| XCB_EVENT_MASK_POINTER_MOTION,
XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC,
XCB_NONE, XCB_NONE, mouse->time);
r0 = xcb_grab_pointer_reply(connection, c0, NULL);
if ((r0 == NULL) || (r0->status != XCB_GRAB_STATUS_SUCCESS)) {
puts("grab failed");
return false;
}
} else {
xcb_ungrab_pointer(connection, mouse->time);
}
return true;
}
#endif
static bool
event_motion(xcb_generic_event_t *nvt) {
xcb_motion_notify_event_t *motion
= (xcb_motion_notify_event_t*)nvt;
if (!!(motion->state & XCB_BUTTON_MASK_1)) {
#if USING_COMPIZ
xcb_screen_t *screen
= xcb_setup_roots_iterator(xcb_get_setup(connection)).data;
xcb_intern_atom_cookie_t c0;
xcb_intern_atom_reply_t *r0;
xcb_client_message_event_t *message;
c0 = xcb_intern_atom(connection, 1, 18, "_NET_WM_MOVERESIZE");
r0 = xcb_intern_atom_reply(connection, c0, NULL);
xcb_ungrab_pointer(connection, motion->time);
xcb_flush(connection);
message = calloc(32, 1);
message->response_type = XCB_CLIENT_MESSAGE;
message->format = 32;
message->window = motion->event;
message->type = r0->atom;
message->data.data32[0] = motion->root_x;
message->data.data32[1] = motion->root_y;
message->data.data32[2] = 8; /* movement only */
message->data.data32[3] = XCB_BUTTON_MASK_1;
message->data.data32[4] = 1; /* source indication normal application */
xcb_send_event(connection, false, screen->root,
XCB_EVENT_MASK_SUBSTRUCTURE_REDIRECT |
XCB_EVENT_MASK_SUBSTRUCTURE_NOTIFY, (char*)message);
xcb_flush(connection);
free(r0);
puts(" started drag XCB_MOTION_NOTIFY");
#else
int32_t values[2];
xcb_query_pointer_cookie_t c0
= xcb_query_pointer(connection, iface0.window);
xcb_query_pointer_reply_t *r0
= xcb_query_pointer_reply(connection, c0, NULL);
xcb_flush(connection);
values[0] = (iface0.mete_box.x += (r0->root_x - xroot));
values[1] = (iface0.mete_box.y += (r0->root_y - yroot));
xroot = r0->roo
Re: Move a window
On Sat, May 31 2025 at 05:14:33 PM +, Carsten Haitzler wrote: what is your problem? You should know how valuable and appreciated your reply is! I think the problem is my thinking! I wanted to support Ubuntu's window manager, but more importantly is that that application run on all Linux. That means Xorg and its protocols. If a manager chooses to support it only through their toolkit that's their right. When a manager tests positive to Xorg, just like say POSIX, you get a full working application. If a feature missing, they file bug report to window manager. It gets fixed than they get removed from blacklist. Or maybe I can figure a test to test for their non-support of features they claim to support instead of current blacklist. That way on their patch feature appears :) So I believe I am going about this wrong. It should be if they support Xorg and its protocols and not about Xorg supporting them. I've read the protocols and can't find I'm lacking. And no one has said different, which I guess what the question should have been. So thank you! It is the help I sought even if its not the answer I expected :) Steve
Re: Move a window
On Sat, May 31 2025 at 05:14:33 PM +, Carsten Haitzler wrote: well you never said what you WANTED to achieve In my original post: And on the 3 tested this 'grab' won't work. It has confines placed on it from moving past edges or 'STRUT's where cursor gets separated from drag point (mouse location). So I trying to move a window within the confines of the display or displays, not 10, 20 or xx number of pixels from the edge. To get window manager to understand the values passed to them or use them. To get the window to follow the pointer. Problem is creating an application and not knowing all tool kits and languages to move a window. It's kinda like using Alt+button, Super+button, or other-combos+button on different flavors to move a window other than the titlebar. I was forced to use this because one said it supported _NET_WM_MOVERESIZE but clearly didn't. Which lead to starting with the basics, Xorg bare, and twm. Issue a XMoveWindow() or xcb_configure_window() and find out as I luckily did, that your application had its window stop 10 pixels from edge with pointer 200 pixels from grab location, yet works 100% of the time on the 3 distributions tested and designed on. Is there a property I'm not defining to get window managers to understand what Xorg clearly does? XMoveWindow() or xcb_configure_window() is clearly defined! You move the window. And even though they use these, how do I tell them to use these? What am I missing? Sorry if original post sounded as complaint or wasn't as succinct as I thought. Steve
Re: MappingNotify Events
On Tue, Jun 17 2025 at 11:22:30 PM +, Steven J Abner
wrote:
Or is it obvious that prior to run loop I create a XMappingEvent to
send with XRefreshKeyboardMapping(), with flush?
This is definitely not the solution! It solves the MappingNotify only
to replace with a need for one to handle XCB_ALLOC_NAMED_COLOR event.
Looking at xcb_refresh_keyboard_mapping() the correct way to handle is
to update my cached values. No messaging back to the server required.
I could not find the source code in libxcb for
xcb_get_keyboard_mapping(). I am guessing that may be the server
response it was looking for?
Here was my last attempt causing the event XCB_ALLOC_NAMED_COLOR:
/* session to hold global values */
void
_xcb_keysym_alloc(xcb_connection_t *connection) {
const struct xcb_setup_t *setup = xcb_get_setup(connection);
xcb_keycode_t min_keycode = setup->min_keycode;
xcb_keycode_t max_keycode = setup->max_keycode;
xcb_get_keyboard_mapping_reply_t *sym_table;
xcb_get_keyboard_mapping_cookie_t cookie;
cookie = xcb_get_keyboard_mapping(connection,
min_keycode,
max_keycode - min_keycode + 1);
/* AFAICT owned by server */
sym_table
= xcb_get_keyboard_mapping_reply(connection, cookie, NULL);
/* owned by server */
session->keysyms = xcb_get_keyboard_mapping_keysyms(sym_table);
session->sym_stride = sym_table->keysyms_per_keycode;
session->sym_min = min_keycode;
/* Added for test purpose only. */
{
XMappingEvent event_map;
event_map.type = MappingNotify;
event_map.serial = 0;
event_map.send_event = false;
event_map.display = display;
event_map.window = 0;
event_map.request = MappingModifier;
event_map.first_keycode = 0;
event_map.count = 0;
XRefreshKeyboardMapping(&event_map);
event_map.request = MappingKeyboard;
event_map.first_keycode = min_keycode;
event_map.count = (max_keycode + 1) - min_keycode;
XRefreshKeyboardMapping(&event_map);
}
xcb_flush(connection);
}
So solution as to what to do with a MappingNotify is just update values:
case XCB_MAPPING_NOTIFY: { /* response_type 34 */
xcb_mapping_notify_event_t *keymap
= (xcb_mapping_notify_event_t*)nvt;
if (keymap->request == XCB_MAPPING_KEYBOARD)
_xcb_keysym_alloc(session->connection);
break;
}
That should even address when someone does actually call one of the
trip functions to cause MappingNotify.
Thanks for listening, and if I'm wrong, please tell me :)
Steve
MappingNotify Events
I'm receiving this signal and uncertain how to handle. The application starts up on a bare x server. I do call, on start up, xcb_get_keyboard_mapping_reply() and xcb_get_keyboard_mapping_keysyms() to read codes for responding to key events. The information from documentation says I get the event in response to XSetModifierMapping(), XChangeKeyboardMapping(), or XSetPointerMapping(). I'm guessing the xcb calls may be calling these? This is my debug output surrounding the event: /* Move */ window 4194309, CONFIGURE_NOTIFY. (100,102,500,500) _process_event window 4194309, CONFIGURE_NOTIFY. (125,423,500,500) _process_event window 4194309, BUTTON_RELEASE Button 1 modifier 256 (485,10) _process_event window 4194309, BUTTON_RELEASE Button 1 modifier 256 (485,10) _default_headerbar_meter /* Redraw Button (move indicator) */ window 4194309, EXPOSE. Region (477,5,14,14) _process_event Unknown event: 34 _process_event Unknown event: 34 Unknown event: 34 _process_event Unknown event: 34 /* Switch to be a resize event */ window 4194309, KEY_PRESS. code 37 modifers 0 keyval ffe3 key_name XK_Control_L _process_event window 4194309, KEY_PRESS. code 37 modifers 0 keyval ffe3 key_name XK_Control_L _default_headerbar_meter window 4194309, KEY_PRESS. code 37 modifers 0 keyval ffe3 key_name XK_Control_L _default_interface_meter window 4194309, KEY_PRESS. code 37 modifers 0 keyval ffe3 key_name XK_Control_L _default_headerbar_meter /* Redraw Button (resize indicator) */ window 4194309, EXPOSE. Region (477,5,14,14) _process_event Note: this code as far as server time a ways from original keysym calls. I include this because I don't know if I'm screwing up. According to documentation, I'm to respond by the xcb equivalent to XRefreshKeyboardMapping(). I'm uncertain if I need to update my pointer to keysyms, recheck stride and min? I'm unaware of me changing anything. If I do respond with XRefreshKeyboardMapping() then do I need to update my pointer/stride/min? Nothing on my limited testing ever showed an issue, but maybe a window manager addressed this, or with no manager the Xterm console addressed this prior to start of application? Sorry if info on event lacking, but I don't know what I'm looking at or for. Steve
Re: Question about the future of Xorg
On Fri, Jun 13 2025 at 08:48:16 PM +, Vasily wrote: Or just continue to support X11 and adjust it for modern needs. Which is mush easy for my opinion. Hard enough dealing with window managers that partially follow protocols, and send signals that you just gotta say 'huh?' through one server. But design for only a specific server and complain to all other server developers 'my application won't work' sounds to me like a strange design.
Re: MappingNotify Events
On Mon, Jun 16 2025 at 11:14:01 AM +, Steven J Abner wrote: I include this because I don't know if I'm screwing up. It appears that I don't know the pre/post-function, or bit, to set keyboard has been accessed prior to or after I make calls to cached the keyboard data. Sorry if info on event lacking, but I don't know what I'm looking at or for. More info: The mapping event only occurs on non-WM. Exception being if it's a spawned process of Xterm with/without going thru gdb. I assume WM just block or ignore? Three different apps running simultaneously, each with three tests to validate keymap, were at startup (caching), and the 2 mapping notify events: MAPPING. min_keycode=8 max_keycode=255 keysyms=0x559a7602d6c0 window 0, MAPPING_NOTIFY. request=1 first=8 count=248 _process_event window 0, MAPPING_NOTIFY. request=0 first=0 count=0 _process_event All 3 at 3 events identical except the pointer to keysyms for each app. So the question becomes: What are/is the pre/post-function(s), or bit to call/set for using xcb_get_keyboard_mapping_reply() and xcb_get_keyboard_mapping_keysyms()? Or is it obvious that prior to run loop I create a XMappingEvent to send with XRefreshKeyboardMapping(), with flush? Steve
Re: Question about the future of Xorg
On Sun, Jun 8 2025 at 12:23:46 AM +, Felipe Contreras wrote: A single statement from a few developers would do much more to dispel those beliefs Personally I'm working on an extension that I hope will get adopted by Xorg. If not I'm hoping other developers could at least adapt my code to make life easier, but since it's tied to Xorg, I want their blessing. Steve
Move a window
Please, I'm begging for help! After over a month of finding a kernel
bug, building Xorg/mesa from scratch, rewriting code, to eliminate this
bug or secret, I've created a program to demonstrate.
I need the secret handshake or password to get any window manager,
except the great! twm to run this.
To build:
gcc -ansi -pedantic -Wall -g -o xmove xmove.c -lxcb
To run for bare xorg:
with no-wm either in xinitrc:
cd
./xmove
or with xterm:
exec $xterm -geometry 120X62+850+0 -name login
and from xterm:
cd
./xmove
with twm:
$twm &
exec $xterm -geometry 120X62+850+0 -name login
and from xterm:
cd
./xmove
from any OS with (arrrg) window manager: use console, not xinitrc
Don't say _NET_WM_MOVERESIZE because it doesn't work on every window
manager.
And on the 3 tested this 'grab' won't work. It has confines placed on
it from moving past edges or 'STRUT's where cursor gets separated from
drag point (mouse location).
PS freedesktop link from EWMH doesn't work, not that the managers
follow, and I don't expect a reply from stack exchange.
Steve
/*
* Move window demo
* Steven J Abner 2025
*/
#include
#include
#include
#include
#include
#include
#include
#include
/* gcc -ansi -pedantic -Wall -Wno-unknown-pragmas -g \
-o xmove xmove.c -lxcb */
typedef struct _PhxInterface PhxInterface;
typedef struct _PhxRectangle { int16_t x, y, w, h; } PhxRectangle;
xcb_connection_t *connection = NULL;
xcb_atom_t WM_PROTOCOLS;
xcb_atom_t WM_DELETE_WINDOW;
int16_t xroot, yroot;
struct _PhxInterface {
PhxRectangle mete_box;
xcb_window_t window;
} iface0 = { {0}, 0 };
#if (__STDC_VERSION__ <= 199901L)
#define RECTANGLE(a,b,c,d,e) \
a.x = b, a.y = c, a.w = d, a.h = e
#else
#define RECTANGLE(a,b,c,d,e) \
a = (PhxRectangle){ b, c, d, e }
#endif
static bool
event_keyboard(xcb_generic_event_t *nvt) {
xcb_key_press_event_t *kp = (xcb_key_press_event_t*)nvt;
xcb_client_message_event_t *message;
message = calloc(32, 1);
message->response_type = XCB_CLIENT_MESSAGE;
message->format = 32;
message->window = kp->event;
message->type = WM_PROTOCOLS;
message->data.data32[0] = WM_DELETE_WINDOW;
message->data.data32[1] = kp->time;
xcb_send_event(connection, false, message->window,
XCB_EVENT_MASK_NO_EVENT, (char*)message);
xcb_flush(connection);
return true;
}
static bool
event_mouse(xcb_generic_event_t *nvt) {
bool locus = ((nvt->response_type & (uint8_t)~0x80) == XCB_BUTTON_PRESS);
xcb_button_press_event_t *mouse
= (xcb_button_press_event_t*)nvt;
if (locus) {
xcb_grab_pointer_cookie_t c0;
xcb_grab_pointer_reply_t *r0;
xroot = mouse->root_x;
yroot = mouse->root_y;
c0 = xcb_grab_pointer(connection, 1, mouse->event,
XCB_EVENT_MASK_BUTTON_PRESS | XCB_EVENT_MASK_BUTTON_RELEASE
| XCB_EVENT_MASK_POINTER_MOTION,
XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC,
XCB_NONE, XCB_NONE, mouse->time);
r0 = xcb_grab_pointer_reply(connection, c0, NULL);
if ((r0 == NULL) || (r0->status != XCB_GRAB_STATUS_SUCCESS)) {
puts("grab failed");
return false;
}
} else {
xcb_ungrab_pointer(connection, mouse->time);
}
return true;
}
static bool
event_motion(xcb_generic_event_t *nvt) {
xcb_motion_notify_event_t *motion
= (xcb_motion_notify_event_t*)nvt;
if (!!(motion->state & XCB_BUTTON_MASK_1)) {
int32_t values[2];
xcb_query_pointer_cookie_t c0
= xcb_query_pointer(connection, iface0.window);
xcb_query_pointer_reply_t *r0
= xcb_query_pointer_reply(connection, c0, NULL);
xcb_flush(connection);
values[0] = (iface0.mete_box.x += (r0->root_x - xroot));
values[1] = (iface0.mete_box.y += (r0->root_y - yroot));
xroot = r0->root_x;
yroot = r0->root_y;
free(r0);
xcb_configure_window(connection, motion->event,
XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y, values);
xcb_flush(connection);
}
return true;
}
static int32_t
process_timers(void) {
return INT_MAX;
}
static bool
process_event(xcb_generic_event_t *nvt) {
switch (nvt->response_type & (uint8_t)~0x80) {
case XCB_KEY_PRESS: { /* response_type 2 */
event_keyboard(nvt);
break;
}
case XCB_KEY_RELEASE: { /* response_type 3 */
break;
}
case XCB_BUTTON_PRESS:/* response_type 4 */
case XCB_BUTTON_RELEASE: {/* response_type 5 */
event_mouse(nvt);
break;
}
case XCB_MOTION_NOTIFY: { /* response_type 6 */
event_motion(nvt);
break;
}
case XCB_ENTER_NOTIFY:/* response_type 7 */
case XCB_LEAVE_NOTIFY: { /* response_type 8 */
break;
}
case XCB_FOCUS_IN: { /* response_type 9 */
xcb_set_input_focus(connection
Re: Move a window
Forgot, Click in window to execute move. Press any key to quit.
Re: Question about the future of Xorg
On Wed, Jun 11 2025 at 05:30:48 PM +, Carsten Haitzler wrote: wayland is a PROTOCOL From this conversation, trying to understand. So: X protocol => X11 => aplications and wayland protocol => wlroots? => compositor/windowmanager => application where compositor is wayland's term for window manager? Steve
Re: evince crashes the X server
On Thu, Jul 10 2025 at 01:33:12 PM +, Vladimir Dergachev wrote: "imprecise_trapezoid_span_converter" I used other than google. If this helps these are only references I found: http://v6.mirror.yandex.ru/NetBSD/NetBSD-release-10/xsrc/external/mit/xf86-video-intel/dist/src/sna/sna_trapezoids.h and http://getfoxy.yandex.ru/NetBSD/NetBSD-release-9/xsrc/external/mit/xf86-video-intel/dist/src/sna/sna_trapezoids.h
