ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
st3r4g has quit [Quit: おやすみ]
Seirdy0 has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
columbar1 has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
newbie has joined #wayland
blue__penquin has joined #wayland
newbie has left #wayland [#wayland]
sih has joined #wayland
<sih>
hi, i'm using this command on ubuntu: gst-launch-1.0 -v videotestsrc ! waylandsink
<sih>
and im getting the error 'Failed to connect to the wayland display '(default)''
<sih>
have i missed some step? i dunno if i need to start a wayland server also
ishitatsuyuki has joined #wayland
<punit>
sih: You need to have a wayland server / compositor running before starting gstreamer pipeline
<sih>
punit:= Can you point me in the right direction on how to get the compositor running (I don't see any compositot running on /run/user/1000/)
<sih>
how do it start it manually from the command line?
<punit>
If you're using weston, running weston-launch should generally be good enough
<punit>
It'll launch the desktop shell on your display if you don't set any particular configure file
<punit>
If that doesn't work, try setting up the log option (man weston) to see where things fail
<sih>
it says i have to add myself to the 'weston-launch' group
<sih>
i added myself to the group
<sih>
but it still gives the same error
<sih>
sudo weston-launch says 'weston-launch: weston-launch must be run from a virtual terminal'
<punit>
Maybe obvious - does "groups" show weston-launch as one of the groups you belong to?
<punit>
Are you using systemd? If so, installing policykit-1 may help..
<punit>
sih: ^^^
<sih>
it doesn't show weston-launch in groups
<sih>
i tried to create and it said it already exists
<sih>
but it doesn't show when i use groups command
<punit>
likely you need to logout and back in for the groups setting to take effect
nerdopolis has quit [Ping timeout: 480 seconds]
* punit
will be back in a bit
sih has quit [Remote host closed the connection]
sih has joined #wayland
<sih>
punit:= weston-launch group shows up, now it says 'weston-launch: weston-launch must be run from a virtual terminal'
<sih>
i tried 'weston' on the command line and it worked, opend up a compositor :)
tzimmermann has joined #wayland
<punit>
sih: Cool!
<sih>
0/ thanks pac85[m]
<sih>
im mean punit
<punit>
:-)
dcz has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
shankaru1 has quit [Ping timeout: 480 seconds]
shankaru has joined #wayland
danvet has joined #wayland
NoGuest17 has quit [Read error: Connection reset by peer]
<gitlab-bot>
wayland issue (Merge request) 149 in wayland "connection: Handle non-nullable strings in wl_connection_demarshal" [Ipc Library, Testing, Merged]
audgirka has joined #wayland
<pq>
fltrz, they do, but you have to explicitly listen to them: set Mesa-specific environment variables, call glGetError(), or hook up KHR_debug extensions in your code.
rasterman has joined #wayland
<jadahl>
wayland!123 should be ready to merge shouldn't it? what are the release plan for libwayland? would be nice with a release with that, and other changes, before any event loop rewrite etc, to make it easier to backport
audgirka has quit [Remote host closed the connection]
audgirka has joined #wayland
hegstal has joined #wayland
mixfix41 has joined #wayland
Lucretia has joined #wayland
mixfix41_ has quit [Ping timeout: 480 seconds]
audgirka has quit [Quit: Leaving]
audgirka has joined #wayland
audgirka_ has joined #wayland
audgirka has quit [Ping timeout: 480 seconds]
audgirka_ has quit [Remote host closed the connection]
audgirka_ has joined #wayland
pnowack has joined #wayland
audgirka_ has quit []
audgirka_ has joined #wayland
audgirka_ has quit [Remote host closed the connection]
<jadahl>
emersion: can't we avoid that awkward server side connector object mess be avoide by making them globals too? or advertising them as IDs with client created objects? the "send long lived events via events" doesn't seem very nice
<emersion>
jadahl: we've discussed this at length in preivous threads
<jadahl>
whats the conclusion?
<emersion>
and this was the less worse solution
<emersion>
making connectors globals isn't nice because you loose the device grouping
<emersion>
making them IDs is very alien for a wayland protocol and makes extending difficult
<jadahl>
arguably as alien as this, but I see your point
<jadahl>
so if a client calls device.destroy, the compositor has a device.connector on the wire, which will be dropped on the floor upon arrival, can't the leak be fixed by binding the lifetime of the connector object to the device? i.e. withdraw the device immediately
<jadahl>
i.e. avoid the awkward destructor free stop/finish dance by tying the connector lifetime to the device
<emersion>
so, no connector.destroy, and the only way to destroy a connector is by destroying the device?
<jadahl>
yes
<emersion>
connectors would be leaked on unplug
<emersion>
well
<jadahl>
they would be "withdrawn" on unplug which would destroy it
<emersion>
"You could try to make your way out of that pitfall by writing in your protocol specification, that when the (parent) object is destroyed, all the child objects will be destroyed implicitly"
<emersion>
in pq's blog post
<jadahl>
right, but its a server side object, so shouldn't the server destroy it, as is done with e.g. callbacks?
<jadahl>
that will maybe race when using it, hmm
<emersion>
callbacks aren't server side objects
<pq>
what if the connector object is used as an argument in a request by the client at the same time the server destroys it?
<jadahl>
emersion: true
<pq>
server-side destroying of wl_callback is safe only because no request ever takes a wl_callback as an argument.
<jadahl>
and the only way to get grouped connectors by having them as globals is by requiring the client to create objects for all of them, receiving the groupness data
<emersion>
i'm also not a fan of throwing a lot of new globals around
<pq>
globals are inherently problematic too, we have the removal race patched up with timeouts.
<jadahl>
i give up, asked for spelling out how the lifetime is managed instead