profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/psychon/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Uli Schlachter psychon In front of his laptop

pavouk/lgi 322

Dynamic Lua binding to GObject libraries using GObject-Introspection

psychon/notify-cat 10

Turn a pipe into notifications

Elv13/awesome-1 8

Semi-official mirror of the awesome window manager from git://git.naquadah.org/awesome.git, updated hourly.

psychon/lualock 5

A screenlocker that's highly configurable in lua

psychon/lgi 2

Dynamic Lua binding to GObject libraries using GObject-Introspection

actionless/awesome 1

Mirror of the awesome window manager repository (http://git.naquadah.org/?p=awesome.git). Please report issues at https://awesome.naquadah.org/bugs/.

amezin/xcb-cpp 0

XCB for C++

CvO-Theory/apt-relabelling 0

Petri Net synthesis where unsolvable LTS are made solvable by splitting labels

psychon/advisory-db 0

Security advisory database for Rust crates published through crates.io

issue commentSmithay/smithay

Minimize transitive dependencies (including dev dependencies)

Looking at x11rb the windows side uses winapi there, so you would have to talk to psychon there.

Yeah, it uses winapi just for a single function: WSAPoll. Which is Microsoft's version of poll and is needed to wait for "is the socket readable" and "is the socket writeable" at the same time. I even published a tiny crate, winapi_wsapoll, that provides safe bindings for WSAPoll just so that I can pretend "look ma, no unsafe code in the crate" (unless you enable the allow-unsafe-code feature which smithay shouldn't do if it does not use XCBConnection). ;-)

Also: Just don't build on Windows. Most likely "anything wayland" does not work there anyway plus I doubt anyone uses X11 on Windows anyway.

DemiMarie

comment created time in 10 hours

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

Hrm. Sorry, I give up. That's 3.8k lines of code, 3.1k of which come from a code generator. Gio's DBus code is just not meant to be used from anything other than C.

Here is my state when I gave up:

local lgi = require("lgi")
local Gio = lgi.Gio
local GObject = lgi.GObject
local GLib = lgi.GLib

local MyApp = lgi.package 'MyApp'
MyApp:class('ExampleObjectSkeleton',  Gio.DBusObjectSkeleton)
MyApp:class('ExampleAnimalSkeleton',  Gio.DBusInterfaceSkeleton)

MyApp.ExampleAnimalSkeleton._property.mood = GObject.ParamSpecString("mood", "Mood", "Mood", nil, { "READWRITE" })
MyApp.ExampleObjectSkeleton._property.animal = GObject.ParamSpecObject("animal", "animal", "animal", MyApp.ExampleAnimalSkeleton, { "READWRITE" })

function MyApp.ExampleAnimalSkeleton._property_set:mood(value)
	self.priv.mood = value
end

function MyApp.ExampleAnimalSkeleton:set_mood(value)
	self.mood = value
end

local vtable = Gio.DBusInterfaceVTable{
	method_call = function(...) print("method call", ...) end,
	get_property = function(...) print("get property", ...) end,
	set_property = function(...) print("set property", ...) end
}
function MyApp.ExampleAnimalSkeleton:do_get_vtable()
	print("get vtable 1 - WHY THE HECK IS THIS NEVER CALLED?")
end

local info = Gio.DBusInterfaceInfo {
	name = "org.gtk.GDBus.Example.ObjectManager.Cat",
	-- Lots of NULLs follow
}
function MyApp.ExampleAnimalSkeleton:do_get_info()
	return info
end

function MyApp.ExampleObjectSkeleton._property_set:animal(value)
	self.priv.animal = value
	-- Not sure if I got this right... In fact, I am almost sure I got this wrong
	self:add_interface(value)
end

function MyApp.ExampleObjectSkeleton:set_animal(value)
	self.animal = value
end

local function example_object_skeleton_new(path)
	return MyApp.ExampleObjectSkeleton{["g-object-path"] = path}
end

local function example_animal_skeleton_new()
	return MyApp.ExampleAnimalSkeleton()
end


local function on_animal_poke(animal, invocation, make_sad, make_happy, ...)
	print("on_animal_poke", animal, invocation, make_sad, make_happy)

	if (make_sad and make_happy) or (not make_sad and not make_happy) then
		invocation:return_dbus_error("org.gtk.GDBus.Examples.ObjectManager.Error.Failed", "Exactly one of make_sad or make_happy must be TRUE")
		return true -- The C code uses a constant for this, but I did not find this anywhere
	end

	if make_sad then
		if animal:get_mood() == "Sad" then
			invocation:return_dbus_error("org.gtk.GDBus.Examples.ObjectManager.Error.SadAnimalIsSad", "Sad animal is already sad")
			return true
		end
		animal:set_mood("Sad")
		animal:complete_poke(animal, invocation)
	elseif make_happy then
		if animal:get_mood() == "Happy" then
			invocation:return_dbus_error("org.gtk.GDBus.Examples.ObjectManager.Error.HappyAnimalIsHappy", "Happy animal is already happy")
			return true
		end
		animal:set_mood("Happy")
		animal:complete_poke(animal, invocation)
	end
	assert(0)
end

local function on_bus_acquired(conn, name, data)
	print("Acquired a message bus connection")

	manager = Gio.DBusObjectManagerServer.new("/example/Animals")
	for n = 0, 10 do
		local object = example_object_skeleton_new(string.format("/example/Animals/%03d", n))
		local animal = example_animal_skeleton_new()
		animal:set_mood("Happy")
		object:set_animal(animal)

		--[[ No thanks, let's skip this for now
		if n % 2 == 1 then
			local cat = example_cat_skeleton_new()
			object:set_cat(cat)
		end
		--]]

		-- FIXME: How to I add the handle-poke signal?!?
		--animal.on_handle_poke = on_animal_poke

		manager:export(object)
	end
	manager:set_connection(conn)
end


local function on_name_acquired(conn, name, data)
	print("Acquired the name", con, name, data)
end

local function on_name_lost(conn, name, data)
	print("Lost the name", con, name, data)
end


-- main

local loop = GLib.MainLoop.new(nil, false)
id = Gio.bus_own_name(Gio.BusType.SESSION,
	"org.gtk.GDBus.Examples.ObjectManager",
	Gio.BusNameOwnerFlags.ALLOW_REPLACEMENT + Gio.BusNameOwnerFlags.REPLACE,
	GObject.Closure(on_bus_acquired), GObject.Closure(on_name_lost), GObject.Closure(loop), nil)

loop:run()
Gio.bus_unown_name(id)

print("end of main")

Perhaps the following code helps you? It shows how to use Gio without using DBusInterfaceSkeleton (but of course you then lose its automatic introspection capabilities): https://github.com/awesomeWM/awesome/blob/ebc9b99ae2817ddd95b5b9b2238881fcd5c777e0/lib/naughty/dbus.lua#L429-L430

joseigor

comment created time in 4 days

pull request commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

because aren't the requests usually small enough so that multiple ones can be written before the socket starts to block

If cairo has to fall back to core protocol (no RENDER available, no shared memory available), then it has to use PutImage and upload raw pixel data. That's an easy way to end up with large requests.

Worse, before being able to draw "that one line" you want to draw, cairo has to basically grab a screenshot of the current contents of the drawable (GetImage requests with a large reply).

I also thought that one could usually avoid using bigger requests.

That might be true, but I'd expect that a proper solution would to also have to take this account. I know that perfect is the enemy of good, but if the requirement is "no blocking", that is usually quite a hard requirement and not "no blocking most of the time".

Currently, though, I can see this pull request mainly paving the way for very complex solutions with very much uncertainty if they help with any real problem.

Yeah, I have to say that I am not really sure which problem this PR is solving. I'd be interested in solving use cases, but I am not sure if lots of complicated code that only might solve part of a problem is a good idea. Sorry.

maybe one could use a separate thread to handle the sending part.

Hm. With Rust and large requests, that would produce lots of lifetime problems...

Perhaps if the goal is "infinite buffer" and "integrate with some main loop mechanism", one could use a Linux pipe/socketpair and give that to libxcb:

  • One end of the socketpair is given to libxcb
  • The other end is given to a thread. This thread reads from the socket and forwards data to the real X11 server. And also does the opposite thing with data from the X11 server. This could also set some flag "some data was read and given to libxcb" which the main thread then uses so that it know to re-check with libxcb.
  • This thread could read more data from the xcb-socket even when forwarding to the X11 server is currently blocked: Infinite buffer!

Basically: This extra socket layer allows to "intercept" data through libxcb.

Dunno if this is really a good idea....

However, when does one really need this? Most GUI programs do not have much useful to do than talking to the X11 server. And for something called xaskpass, I wouldn't expect something that complex. A slow X11 server just means "everything is slow" and that can't be worked around.

user827

comment created time in 4 days

pull request commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

Late replies are not really easily solvable.

However, if you want to avoid blocking your thread, then dealing with late replies is not enough: Sending a request can also block in the write() syscall. So, if you would really want to avoid blocking, you'd also need some asynchronous way to send requests. And this runs into borrowing-issues: Since requests can be up to 16 MiB large, copying everything into a send buffer is too slow and thus the request sending code needs to take ownership of the buffers that you want to send.

I hope the above makes a bit of sense. I feel like I am not formulating this point nicely...

user827

comment created time in 6 days

pull request commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

If I understand xaskpass's code correctly, there are just two requests that it wants to handle asynchronously: GrabKeyboard and GetProperty (called Selection in the code). Now I am even more confused about what is going. Lots of other stuff waits blockingly for replies.

The main loop seems to be about some complicated integration with Tokio. It seems a lot more sensible to just spawn an extra thread that does the wait_for_event(); send_event_via_channel() that I suggested above.

I am looking forward to your explanation of what is going on and will now stop this github comment spam. Sorry for that.

user827

comment created time in 6 days

CommitCommentEvent

Pull request review commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

 where         Ok(R::try_parse(self.raw_reply()?.as_ref())?.0)     } +    /// Poll for a raw reply that the server sent.+    pub fn poll_raw_reply(me: &mut Option<Self>) -> Result<Option<C::Buf>, ReplyError> {+        if let Some(cookie) = me {+            let conn = cookie.raw_cookie.connection;+            if let Some(reply) = conn.poll_for_reply_or_error(cookie.sequence_number())? {+                std::mem::forget(me.take());+                return Ok(Some(reply));+            }+        }+        Ok(None)+    }++    /// Poll for a reply that the server sent.+    pub fn poll_reply(me: &mut Option<Self>) -> Result<Option<R>, ReplyError> {

Hm.... not really the easiest API to use. I was expecting something like pub fn poll_reply(self) -> Result<Result<R, ReplyError>, Self> (which is also a horrible API!)

Do you have some code example that uses some of the proposed APIs?

user827

comment created time in 6 days

Pull request review commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

 impl<S: Stream> Connection for RustConnection<S> {         }     } +    fn poll_for_queued_raw_event_with_sequence(+        &self,+    ) -> Result<Option<RawEventAndSeqNumber>, ConnectionError> {+        let mut inner = self.inner.lock().unwrap();+        Ok(inner.poll_for_event_with_sequence())

You could leave behind a // TODO saying that the queued part is not implemented, or something like that.

user827

comment created time in 6 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentpsychon/x11rb

Add poll for reply functions and poll for queued events.

cookie reply polling

Sorry, but why? I know that some people want this, but I think you would basically end up with callback hell if you go down that route. Is there some "nice" code possible?

Also, that approach is basically impossible to use thread-safely. If another thread can also access the connection, then new events can be read at any time from the socket and it becomes impossible to integrate the X11 FD with the main connection.

I gave up trying to make this work. My suggestion would be to just start a thread that does something like while let Ok(event) = conn.wait_for_event() { send_to_main_thread_via_channel(event); }.

(I haven't yet looked at the actual PR, but will do that next.)

user827

comment created time in 6 days

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

Hm... I tried to add the following, but the function is not called (still same NULL pointer as before). Now I am back in "I do not know how this work and would like to have a working example in C that can be translated". Sorry.

function MyApp.MyDBusInterfaceSkeleton:do_get_vtable()
	print("You have to somehow implement this method")
end
joseigor

comment created time in 6 days

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

The crash happens here:

GDBusInterfaceVTable *
g_dbus_interface_skeleton_get_vtable (GDBusInterfaceSkeleton *interface_)
{
  GDBusInterfaceVTable *ret;
  g_return_val_if_fail (G_IS_DBUS_INTERFACE_SKELETON (interface_), NULL);
  ret = G_DBUS_INTERFACE_SKELETON_GET_CLASS (interface_)->get_vtable (interface_);
  g_warn_if_fail (ret != NULL);
  return ret;
}

Specifically, it happens when calling the get_vtable function. This function pointer is NULL.

joseigor

comment created time in 6 days

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

$ cat > /tmp/t.lua && lua /tmp/t.lua 
local lgi = require("lgi")
local Gio = lgi.Gio
local GObject = lgi.GObject
local GLib = lgi.GLib

local MyApp = lgi.package 'MyApp'
MyApp:class('MyDBusInterfaceSkeleton',  Gio.DBusInterfaceSkeleton)

-- Override get_info() method of Gio.DBusInterfaceSkeleton
function MyApp.MyDBusInterfaceSkeleton:do_get_info()
      return Gio.DBusInterfaceInfo{
        name = "org.test",
        methods = nil,
        signals = nil,
        properties = nil,
        annotations = nil
    }
end

-- create a instace of MyDBusInterfaceSkeleton which implements Gio.DBusInterfaceSkeleton
local interface_ske = MyApp.MyDBusInterfaceSkeleton()

local obj_man = Gio.DBusObjectManagerServer{object_path ="/object"}  
local obj_ske = Gio.DBusObjectSkeleton.new("/object/1")

obj_man:export(obj_ske)

-- Line below causes SEGMENTATION FAULT
obj_ske:add_interface(interface_ske)

First line is what I entered in my shell. The rest is copy&paste from your post (with a final ctrl+d for "end of file). I tested this with all of lua5.1, 5.2, 5.3 and luajit.

joseigor

comment created time in 7 days

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

Sorry, but that does not segfault here :-(

joseigor

comment created time in 7 days

issue commentpavouk/lgi

Example of how to implement *DBusInterfaceSkeleton* abstract class

Do you happen to have some C example code for me to translate?

Last time I looked at this, I gave up since I failed to figure out how "all the pieces fit together".

(From the top of my head: I also don't know how the subclassing works exactly. But hopefully I can figure this out when I don't have to figure out Gio's dbus code at the same time.)

joseigor

comment created time in 9 days

pull request commenti3/i3

Fix focus issue when moving windows across output boundary

The proper fix would be to not have the focus follows mouse happen in this case where i3 itself is the one moving the mouse

<details><summary>Slightly off-topic description on how AwesomeWM deals with this problem</summary>

AwesomeWM does this via some ugly code: https://github.com/awesomeWM/awesome/blob/1d55ae09aa487a82f2808e82a8884123e2400722/mouse.c#L257-L263 https://github.com/awesomeWM/awesome/blob/1d55ae09aa487a82f2808e82a8884123e2400722/objects/client.c#L1669-L1701

Once upon a time, the code literally changed the event mask of each window so that the X11 server does not generate any events for the cursor entering/leaving windows, then it warped the cursor, then it changed the event masks back to their original value.

These days, awesomeWM just sends a request, writes down its sequence number, warps the mouse cursor, then sends another request. Incoming events with a sequence number between these two values are then later ignored: https://github.com/awesomeWM/awesome/blob/1d55ae09aa487a82f2808e82a8884123e2400722/event.c#L1062-L1090

(The GrabServer is there to hopefully block "everyone else" from doing anything with the X11 server so that we don't accidentally also ignore other events. The old code IMO also would have needed this, but AFAIK it was not present.) </details>

algmyr

comment created time in 11 days

pull request commentSmithay/smithay

Add Foward/Back mouse buttons

is there some known formula for converting x11 button codes to libinput ones?

If I understand your correctly: Seems like you need the inverse of this: https://sources.debian.org/src/xserver-xorg-input-libinput/1.1.0-1/src/xf86libinput.c/?hl=1508#L216-L234


static inline unsigned int
btn_linux2xorg(unsigned int b)
{
	unsigned int button;

	switch(b) {
	case 0: button = 0; break;
	case BTN_LEFT: button = 1; break;
	case BTN_MIDDLE: button = 2; break;
	case BTN_RIGHT: button = 3; break;
	/* tablet button range */
	case BTN_STYLUS: button = 2; break;
	case BTN_STYLUS2: button = 3; break;
	default:
		button = 8 + b - BTN_SIDE;
		break;
	}

	return button;
}

Also relevant for the above:

$ grep -A 3 BTN_LEFT /usr/include/linux/input-event-codes.h ; echo ;  grep -B 1 BTN_STYLUS2 /usr/include/linux/input-event-codes.h                                                                                       
#define BTN_LEFT		0x110
#define BTN_RIGHT		0x111
#define BTN_MIDDLE		0x112
#define BTN_SIDE		0x113

#define BTN_STYLUS		0x14b
#define BTN_STYLUS2		0x14c
i509VCB

comment created time in 11 days

pull request commentawesomeWM/awesome

Fix 3458

Uhm.... Guys? Really? https://github.com/awesomeWM/awesome/blob/1d55ae09aa487a82f2808e82a8884123e2400722/tests/test-screenshot.lua#L94

Aire-One

comment created time in 13 days

pull request commentawesomeWM/awesome

Fix 3458

This error also happens for me locally (I just tried tests/run.sh test-screenshot.lua test-screenshot.lua test-screenshot.lua and that failed to kill its Xephyr. Now it immediatelly crashes on the first run. No idea why "Xephyr is already running" makes a difference).

Valgrind says this is a use-after-free and the backtrace matches / makes sense (pixman_image_unref is the right function to free the image data):

==29898== Invalid read of size 4
==29898==    at 0xFA8C18D: convert_no_alpha (gdkpixbuf-drawable.c:228)
==29898==    by 0xFA8C18D: gdk_pixbuf_get_from_surface (gdkpixbuf-drawable.c:303)
==29898==    by 0x59F79F9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x59F6B5E: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x7502BBB: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.3-lgi.so.0.0.0)
==29898==    by 0x52D0584: luaD_precall.part.3 (ldo.c:365)
==29898==    by 0x52DD354: luaV_execute (lvm.c:1134)
==29898==    by 0x52D0997: luaD_call (ldo.c:496)
==29898==    by 0x52D09C0: luaD_callnoyield (ldo.c:506)
==29898==    by 0x52CFD81: luaD_rawrunprotected (ldo.c:142)
==29898==    by 0x52D0C4A: luaD_pcall (ldo.c:727)
==29898==    by 0x52CC593: lua_pcallk (lapi.c:968)
==29898==    by 0x52E1F7F: luaB_xpcall (lbaselib.c:441)
==29898==  Address 0x109431d0 is 410,000 bytes inside a block of size 3,145,728 free'd
==29898==    at 0x483C0FB: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29898==    by 0x5CE7991: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.40.0)
==29898==    by 0x5CE78E8: pixman_image_unref (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.40.0)
==29898==    by 0x5077714: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
==29898==    by 0x50B4981: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
==29898==    by 0x50B575A: cairo_surface_finish (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
==29898==    by 0x59F79F9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x59F6B5E: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x7502BBB: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.3-lgi.so.0.0.0)
==29898==    by 0x52D0584: luaD_precall.part.3 (ldo.c:365)
==29898==    by 0x52DD354: luaV_execute (lvm.c:1134)
==29898==    by 0x52D0997: luaD_call (ldo.c:496)
==29898==  Block was alloc'd at
==29898==    at 0x483E581: calloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==29898==    by 0x5CB1241: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.40.0)
==29898==    by 0x5CB12E8: ??? (in /usr/lib/x86_64-linux-gnu/libpixman-1.so.0.40.0)
==29898==    by 0x5077EFC: ??? (in /usr/lib/x86_64-linux-gnu/libcairo.so.2.11600.0)
==29898==    by 0x59F79F9: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x59F6B5E: ??? (in /usr/lib/x86_64-linux-gnu/libffi.so.8.1.0)
==29898==    by 0x7502BBB: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.3-lgi.so.0.0.0)
==29898==    by 0x52D0584: luaD_precall.part.3 (ldo.c:365)
==29898==    by 0x52DD5D4: luaV_execute (lvm.c:1149)
==29898==    by 0x52D0997: luaD_call (ldo.c:496)
==29898==    by 0x52D09C0: luaD_callnoyield (ldo.c:506)
==29898==    by 0x52CFD81: luaD_rawrunprotected (ldo.c:142)
Aire-One

comment created time in 13 days

pull request commentawesomeWM/awesome

Fix 3458

<details><summary>TL;DR: No idea</summary>

So it probably depends on how fast the computer is?

I still haven't read all the context, but my first reaction to the following was "that sounds like this just needs to do something slow".

The only necessary part turned out to be creating a cairo surface with the size of the screen (or greater) beforehand:

This would also match things like the following from #3458

I tried to reproduce it in gdb and both tests went through

This sounds a lot like a use-after-free: https://github.com/awesomeWM/awesome/issues/3458#issuecomment-940399907 But... I am confused. I cannot see any pointer dereference at the line that supposedly caused a segfault...

Hm... Sadly cairo_surface_get_reference_count is not made available by LGI... But this theory does not match with the "depends on something slow/fast on the X11 server".

And at this point, the code is trying to convert the result from copy_to_image_surface to a pixbuf. It is working with a copy of the data and no X11 server is involved?!

Perhaps... sprinkle in some status checks? Is one of the cairo surfaces in an error state? (.status ~= "SUCCESS").... Hm, no, that cannot be the cause author. GdkPibux checks the surface status and... everything.

Perhaps... some calls to cairo_surface_write_to_png (:write_to_png("/tmp/foo.png")). If there is a problem with the image content pointers, this should also crash.

</details>

Aire-One

comment created time in 13 days

issue commenti3/i3

Multiple monitors breaking after long time disconnect

Random idea: Try xrandr --current. xrandr --query / xrandr makes the X11 server re-query the hardware for its current state. With --current it just provides the newest information that it has. If that makes a difference.... I am not sure what that tells us. So, feel free not to test this, but I still wanted to mention this.

gczgcz2015

comment created time in 13 days

issue commentlxqt/lxqt-panel

Panel reserve space is broken in i3

<details> <summary>I think this comment is not too helpful currently, but still it's partly relevant.</summary>

For one, a geometry with height = 0 would be invalid,

I'm not quite sure where this height = 0 comes from, but Qt automatically ensures that the values are valid. If I read this code correctly, it will translate height = 0 to height = 1:

https://github.com/qt/qtbase/blob/2b6500cd15c0a41cf3e5eea8178e2044012dbd97/src/plugins/platforms/xcb/qxcbwindow.cpp#L575-L582

I did not look at the i3 logs, but since no resize to height = 1 appears in there, I guess this comment is not really helpful. </details>

iamthesenate1

comment created time in 13 days

Pull request review commentSmithay/smithay

X11 backend

 where             0,             x11rb::NONE,    // Let the X server pick the most suitable crtc             x11rb::NONE,    // Do not wait to present-            x11rb::NONE,    // We will wait for the X server to tell us when it is done with our pixmap.+            x11rb::NONE,    // We will wait for the X server to tell us when it is done with the pixmap.             OPTIONS.into(), // No special presentation options.-            msc,            // TODO: Handle target msc+            msc,             0,             0,             &[], // We don't need to notify any other windows.         )?; -        // Take the wrapper away since the X server will give us the pixmap's xid back when we-        // receive notification that presentation is completed. At that point we can reconstruct-        // the wrapper and drop.+        // Forget the wrapper since the X server will give us the pixmap's id back when we receive+        // notification that presentation is completed. At that point we can reconstruct the+        // wrapper and drop.

Without having looked closely at this (sorry if I am wrong): Most of the time, you can directly free a Pixmap even though something indirectly still refers to it. They seem to be reference-counted in the X11 server, or something like that.

So: If all you do with the pixmap is to FreePixmap when the event comes, it might already work to just do this directly after present_pixmap().

i509VCB

comment created time in 15 days

PullRequestReviewEvent

issue openedpsychon/x11rb

Consider calling recvmsg with `MSG_CMSG_CLOEXEC` so that received sockets have `CLOEXEC` set.

As suggested by @DemiMarie here: https://github.com/Smithay/smithay/pull/371/files/23a779d2e33b1a8755282db9033fb00d39c839d9..591882e222327880adf18a34317902b2f499c3d3#r723795883

created time in 19 days

Pull request review commentSmithay/smithay

X11 backend

 impl X11Surface {         // provider being NONE tells the X server to use the RandR provider.         let dri3 = connection.dri3_open(screen.root, x11rb::NONE)?.reply()?; -        let drm_device_fd = dri3.device_fd;--        // Duplicate the drm_device_fd otherwise we will segfault.-        let drm_device_fd: RawFd = fcntl::fcntl(-            drm_device_fd.as_raw_fd(),-            fcntl::FcntlArg::F_DUPFD_CLOEXEC(3), // Set to 3 so the fd cannot become stdin, stdout or stderr-        )-        .map_err(AllocateBuffersError::from)?;+        // Take ownership of the container's inner value so we do not need to duplicate the fd.+        let drm_device_fd = dri3.device_fd.into_raw_fd();          let fd_flags =-            nix::fcntl::fcntl(drm_device_fd.as_raw_fd(), nix::fcntl::F_GETFD).expect("Handle this error");-        // No need to check if ret == 1 since nix handles that.+            fcntl::fcntl(drm_device_fd.as_raw_fd(), fcntl::F_GETFD).map_err(AllocateBuffersError::from)?;          // Enable the close-on-exec flag.-        nix::fcntl::fcntl(-            drm_device_fd.as_raw_fd(),-            nix::fcntl::F_SETFD(-                nix::fcntl::FdFlag::from_bits_truncate(fd_flags) | nix::fcntl::FdFlag::FD_CLOEXEC,+        fcntl::fcntl(+            drm_device_fd,+            fcntl::F_SETFD(+                fcntl::FdFlag::from_bits_truncate(fd_flags) | fcntl::FdFlag::FD_CLOEXEC,

This could easily be done for x11rb's RustConnection by patching the code here: https://github.com/psychon/x11rb/blob/198f62ca959a9285e5cc79e062e4d02265009d82/src/rust_connection/stream.rs#L442

However, libxcb basically does the same and even if that code were changed, it would take a long time until that code change reaches people's systems: https://github.com/freedesktop/xcb-libxcb/blob/ee9dfc9a7658e7fe75d27483bb5ed1ba4d1e2c86/src/xcb_in.c#L982

What is more important? Consistency between XCBConnection and RustConnection or having CLOEXEC set? Hm... can anyone think of some downside of CLOEXEC being set? When would one want to pass a FD received via X11 to a child process...?

Okay, I guess this should simply be changed.

i509VCB

comment created time in 19 days

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent