ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
midgard has quit [Quit: Bye]
r00tobo has quit [Quit: Quit]
TheCaptain82970403198578471379 has quit []
midgard has joined #wayland
TheCaptain82970403198578471379 has joined #wayland
JoshuaAshton has quit [Remote host closed the connection]
JoshuaAshton has joined #wayland
fvok4_ has joined #wayland
manuels2 has quit [Quit: Ping timeout (120 seconds)]
manuels2 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
Saijin_Naib has left #wayland [#wayland]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Brainium_ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
Leopold_ has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
utsweetyfish has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
PuercoPop has joined #wayland
Brainium_ has quit []
sgm has quit [Remote host closed the connection]
privacy has joined #wayland
sgm has joined #wayland
PuercoPop has quit [Read error: Connection reset by peer]
kts has joined #wayland
agd5f_ has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #wayland
Company has quit [Quit: Leaving]
privacy has quit [Quit: Leaving]
kts has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
caveman has quit [Remote host closed the connection]
<pq>
swick[m], awesome :-) I installed the vale extension in vscode too, but I guess I need to remove it, because it seems to run on all projects instead of configured ones. Worse, it is flagging every single word as failing spellcheck.
<pq>
hmm, it wasn't vale...
mclasen has quit [Ping timeout: 480 seconds]
mclasen has joined #wayland
mvlad has joined #wayland
mclasen has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
privacy has joined #wayland
mclasen has joined #wayland
Brainium has joined #wayland
Fxzxmic has joined #wayland
shoragan has quit [Quit: quit]
nmeum has quit [Remote host closed the connection]
<Nova[m]>
is there a protocol in development for full application save/restore? like after the client has been launched it is given data from a previous session that it gave the compositor?
<Nova[m]>
with that one the app is the one to save the data and ask the compositor to restore its toplevel position but that doesn't work for the case where the compositor launches an app instance and gives it data
<Nova[m]>
s/save/add/, s/data/toplevel/
<Nova[m]>
basically, since the compositor i'm making is for AR/VR it's a necessity to have the compositor ask the app to give it all the data it needs to give back to it to restore its state
<Nova[m]>
because if you leave a 2D app at your house, go 2 cities over, then come back it should be there but it can't be still running or suspended in RAM
<bl4ckb0ne>
shouldnt that be handled by the compositor?
<Nova[m]>
yes, but the compositor can't do it alone
<Nova[m]>
it has to get some state data from the apps and then hand it back to the apps when launching again when they're reloading
<Nova[m]>
i already got it working for the stardust protocol and it's very seamless, but it doesn't work for 2D apps since wayland doesn't have anything like it
<Nova[m]>
basically, this is the equivalent of an android bundle object
<emersion>
why can't the app save its state on its own?
<Nova[m]>
because it could have multiple instances in different places
<emersion>
yes?
<emersion>
compositor gives the app an ID for the current session
<emersion>
the app can save its state in a different place for each ID
<Nova[m]>
right, but can the compositor say "ok now restore session from this ID" though?
<emersion>
with the protocol, i believe so
<Nova[m]>
looking at the protocol i thought the app was the one to decide which session it is using
<emersion>
hm, maybe i'm misremembering
<emersion>
at any rate, i don't think it's a good idea to pass around the app's state to the compositor
<bl4ckb0ne>
^
<bl4ckb0ne>
also cant you just suspend the machine?
<Nova[m]>
no because this is all day XR so it'd be wearing a headset all that time and needing to unload an app that's physically far away
<Nova[m]>
it's for spatial persistence
<Nova[m]>
the way it works in the stardust protocol is the client must implement a method that gives the compositor its state whenever the compositor requests it
<Nova[m]>
s/compositor/server/
<Nova[m]>
then the server might launch the app and will send it back the state it gave as the first message
<Nova[m]>
so the app can now take that and restore its state
<Nova[m]>
the water bottle model is exactly where it was left, but if you had multiple of them it'd launch multiple instances and give each different data
<Nova[m]>
s/data/state/
<Nova[m]>
s/data/state corresponding to all the instances in that location that were unloaded/
<Nova[m]>
that's what i need that the session management protocol doesn't do
<Nova[m]>
(i don't know how to launch apps just as they were launched before so for now just filtering out every one not being run by the same user as the compositor and yoinking their cmdline to use later)
<Nova[m]>
will have to find a better method that takes into account flatpaks, but regardless... wayland clients can't be fed data they had previously
<Nova[m]>
idk if this is better as a portal or a wayland protocol, but i'm willing to work on whatever is best to get this working
<bl4ckb0ne>
how does it work? do you just copy all of the client's memory and put it back?
<Nova[m]>
no, the client submits a byte array (eventually a fd or such) that the server stores
<Nova[m]>
but if the client just submits a string and stores its own stuff in its own state folder that'd be fine too
<bl4ckb0ne>
that sounds like a security issue
<Nova[m]>
* server stores as well as spatial anchors (spatial positions that are persisted)
kts has joined #wayland
<Nova[m]>
how would it be a security issue?
<Nova[m]>
* fine too, the key is to be able to get it to load different data per instance
<Nova[m]>
* fine too, the key is to be able to get it to load different data per instance so you can have the exact same app in the same state in the same physical position
<Nova[m]>
it's what android and iOS both do for app save/restore
<Nova[m]>
* server stores as well as spatial anchors (spatial positions that are persisted) and is given it back when it's started again by the compositor
<Nova[m]>
* server stores as well as spatial anchors (spatial positions that are persisted) and is given it back when it's started again by the compositor... the byte array is serialized/deserialized by the client itself.
<Nova[m]>
a protocol for this would also benefit linux phones too, letting them kill processes to save resources instead of pausing them and then when the user switches back to them reloading them with their state given back to them to reload
<Nova[m]>
s/reload/deserialize and apply/
kts has quit [Ping timeout: 480 seconds]
<Nova[m]>
it's a nice to have thing on phones but kinda crucial for all day XR
kts has joined #wayland
<zamundaaa[m]>
Nova: we do need a way for the compositor (or rather, desktop environment or whatever starts apps) to tell apps to restore a specific session
<zamundaaa[m]>
But it's not necessarily the compositor that has to store the app's session data
<Nova[m]>
that's fine, as long as the session can be specified to the app then whoever stores it can do what they like
<Nova[m]>
so, should i make a comment/PR to session management for this case?
<Nova[m]>
probably just an event for the compositor to send over to tell the client that it should restore a given session ID
<zamundaaa[m]>
I don't think that makes sense
<zamundaaa[m]>
That's a bit late in the process
<zamundaaa[m]>
Like, it could just be a flag in launch arguments for the app
<Nova[m]>
oh it's about to be merged? shoot i was too late
<zamundaaa[m]>
Nova: no, I mean late in the process of app startup
<zamundaaa[m]>
The protocol is quite far from being done
oliver has quit [Quit: Quit]
<Nova[m]>
oh well... idk how to do it across all apps and early in the process
<Nova[m]>
this has to be a standard thing after all
<Nova[m]>
actually... this is kinda universal across everything
<Nova[m]>
so universal it might be best to use an environment variable
<zamundaaa[m]>
yeah, that's what xdg activation does too
<Nova[m]>
is xdg activation already covering the use case i want?
<zamundaaa[m]>
no
<Nova[m]>
ok, yeah i figured
<zamundaaa[m]>
it's about window focus
<Nova[m]>
xdg activation is so hard to understand for me
<Nova[m]>
and DESKTOP_SESSION_ID doesn't actually work for most apps, they don't pass it to the compositor
caveman has joined #wayland
<Nova[m]>
* and `DESKTOP_SESSION_ID, * DESKTOP_SESSION_ID` doesn't
<Nova[m]>
even though afaik they *should*
<Nova[m]>
so... this is ideal as an XDG standard that doesn't fall under portals or wayland but is like the icon spec or such?
<Nova[m]>
who do i even talk to about starting the process to make that standard? :S
<drakulix[m]>
For wayland apps you want to use XDG_ACTIVATION_TOKEN instead of DESKTOP_SESSION_ID (or rather set both, since you can't know what window protocol the app uses).
<Nova[m]>
right, but the app only sends that through to the compositor so you can tie the state of the launcher to the wayland client that connects to your compositor right?
<Nova[m]>
* right, but the app only sends that through to the compositor so you can tie the state of the way it was launched to the wayland client that connects to your compositor right?
<drakulix[m]>
Sure, you save the state, when the launcher creates the token and then use that, when you get the request from the application using the token.
<zamundaaa[m]>
Nova: "XDG" is just a namespace for Wayland protocols here, nothing more or less
<zamundaaa[m]>
defining a standard for session management can and should happen in the process of defining the protocol
<Nova[m]>
wait so this is the right channel to talk about this in? i am so lost :S
<zamundaaa[m]>
yes
<Nova[m]>
ok good phew
<Nova[m]>
so, i like the environment variable strategy... but somehow the app has to recieve a request to save its state from somewhere
<Nova[m]>
* from somewhere and have an ID given to it
<Nova[m]>
given that's not particularly tied to wayland or anything, would that be a portal?
<Nova[m]>
* given that's not particularly tied to wayland or anything, would a portal be best?
<zamundaaa[m]>
stopping a session would definitely be tied to Wayland
<Nova[m]>
it wouldn't be stopping a session
<zamundaaa[m]>
sure it would. Sessions are per app mind you
<Nova[m]>
it'd just be going "hey app, save your state and associate that state with this ID that you might be launched with"
<Nova[m]>
* launched with later"
<Nova[m]>
that state isn't necessarily wayland state, it could be X state or stardust state or whatever
<zamundaaa[m]>
session management with X11 is a lost cause, I wouldn't even think about it in this context
<Nova[m]>
ok fair x is dead and we killed it
<zamundaaa[m]>
How the proposed protocol works is pretty much that the app can ask the compositor to give it a session, and then it gets an ID for that session
<zamundaaa[m]>
The app's own data could just be tied to that ID
<Nova[m]>
but stardust has its own state too
<Nova[m]>
i made a separate stardust protocol that's not tied to wayland given just how different stardust is from every wayland use ever
<Nova[m]>
and ideally i'd like to use the same session IDs and all
<zamundaaa[m]>
How to integrate between your protocol and the compositor is up to you
<zamundaaa[m]>
You could just have the compositor associate IDs internally, or make it be passed through the protocol
<mclasen>
xsmp never really got off the ground. I'm doubtful that a Wayland session save/restore protocol will fare much better
<davidre>
Firefox uses xsmp on wayland :)
<Nova[m]>
this is why i basically forced everyone using the stardust protocol to save their state if their app is more complicated than a static floating cube
<Nova[m]>
saving/restoring state is stupidly important for XR
<Nova[m]>
mclasen: why didn't it get off the ground?
<Nova[m]>
zamundaaa[m]: what it currently doesn't do is tell the app that it should restore a given session ID from the start
<zamundaaa[m]>
yeah, that could be done through an environment variable
<mclasen>
I don't know that anybody has done a root cause analysis. My take is that its a mixture of complex/ambition protocol and insufficient toolkit-level support
<Nova[m]>
ok awesome, so what should that be called?
<Nova[m]>
`XDG_SESSION_ID` would be too confusing
<Nova[m]>
since we have `XDG_ACTIVATION_TOKEN` and `DESKTOP_SESSION_ID`
<zamundaaa[m]>
XDG_SESSION_RESTORE_ID maybe. The exact name isn't too important
<davidre>
FWIW we Qt/KDE uses the XSMP hooks to store app state
<Nova[m]>
that makes sense
<davidre>
Stuff like toolbar config, window size, etc..
<Nova[m]>
is xsmp tied to xorg? aka is it going to die soon?
<davidre>
xsmp is not part of the xserver
<davidre>
It's a protcol like wayland. But most clients do not use it on wayland
<Nova[m]>
oh huh, is that something that is adequate for use or is it worth replacing?
<davidre>
I only know of firefox which even uses it as a wayland client
<davidre>
XSMP is not really nice in my opinion
<Nova[m]>
reason enough to replace it if barely anyone uses it and it sucks
<Nova[m]>
* it sucks and we need a session restore thing
<davidre>
It involves client passing commands to the server to execute to restore/discard state
<zamundaaa[m]>
yeah it's beyond "not really nice"
<davidre>
Which is very questionable
<mclasen>
xsmp is defined using ice - the dbus of a previous generation
<Nova[m]>
ohno
<Nova[m]>
it's worse than dbus? :0
<davidre>
the actual wire procotol is the least of the problems
<Nova[m]>
okay, so in practice if we say "this is the environment variable that if set you should restore the session for"
<Nova[m]>
and then in the wayland protocol go "the session id you got might be passed back in this env variable"
<Nova[m]>
* env variable and you must (or at least really should) restore its state"
<Nova[m]>
and then have stardust use the same environment variable for its session IDs
<mclasen>
I am very dubious about involving environment variables in this
<Nova[m]>
okay, well what other mechanism could let the compositor/session manager tell the app to restore its state according to a given session ID early enough in the lifecycle that it won't cause a mess?
<Nova[m]>
if we do it when the xdg session manager global is bound it may be too late
<Nova[m]>
* too late, the app might have already started launching without the state we want it to start with
<mclasen>
I think that is the apps problem to solve
<Nova[m]>
* do it with a wayland event when the, * too late, the app might have already started launching without the state we want it to start with
<zamundaaa[m]>
I think it depends a lot on what kind of state you want to restore too
Fxzx_mic has quit [Read error: Connection reset by peer]
<Nova[m]>
it's easy to *say* but in practice i think most apps will just go "no not worth it"
<zamundaaa[m]>
or rather at what level you want session restoration to happen
<zamundaaa[m]>
If it's on the toolkit level, doing it when the global is bound should be fine
<zamundaaa[m]>
If it's on the app level, the env var is probably better
<Nova[m]>
what do you mean by toolkit vs app level?
Fxzx_mic has joined #wayland
<Nova[m]>
like, if it's just the window sizes or if it's the exact page that was open before?
<Nova[m]>
because in the case i'm talking about it should really be the entire UI that was open when its state was closed will be there when you get back...
<Nova[m]>
so even the text editing field and open document should be as it was before
<Nova[m]>
* was before ideally
<Nova[m]>
but of course even just being the same window size and open document would be nice even if the smallest details aren't preserved
<Nova[m]>
* size and position and open document
<mclasen>
env vars have the wrong characteristics - they get inherited, and unsetting them isn't threadsafe
<zamundaaa[m]>
If you want anything except window properties, you need the app to actually directly support it
<Nova[m]>
zamundaaa[m]: yep, that's fine since toolkits can often assist there
<Nova[m]>
idk if gtk can but i know Qt can since it does for macOS
<Nova[m]>
* for macOS/iOS/android to some extent
<Nova[m]>
* for macOS/iOS/android/windows to some extent
<Nova[m]>
mclasen: ok the inheritance part is a problem, but what better mechanism is there?
<Nova[m]>
wait hang on technically all the other platforms get their session save/restore from display server adjacent things... maybe it wouldn't be too late in the app launching?
<Nova[m]>
but you can easily call the session save/restore stuff earlier except with android activities
<Nova[m]>
but activities do way more than wayland anyway...
<zamundaaa[m]>
We need some sort of race free way to detect that an app has been started for session restoration purposes
<zamundaaa[m]>
Outside of that, going through the Wayland protocol would be fine
<mclasen>
there's overlap here with activation, for sure
kts has joined #wayland
<Nova[m]>
yeah, and that uses env vars
<zamundaaa[m]>
mclasen: right, a special xdg activation token could work
<zamundaaa[m]>
but the compositor doesn't get that until there's a window to activate
<Nova[m]>
does it matter that unsetting env vars is thread unsafe?
<Nova[m]>
if it doesn't really matter it'd be easy to just tell app devs "hey unset this env var the moment you read it"
<mclasen>
it means you have to read, stash and unset the env var early on, before other threads start poking at the environment
<mclasen>
and it is a bit hard to know when that is safe to do
<Nova[m]>
what's wrong with other threads poking at the environment though?
<Nova[m]>
hell, the only reason to unset the env var is to stop any processes launched by the app from trying to restore the same state
<kennylevinsen>
env vars are suboptimal for things that aren't meant to affect the entire subtree of processes... It isn't entirely unheard of to unset env vars early on (like WAYLAND_SOCKET), but it feels a bit icky
<mclasen>
a setenv call in thread A makes a getenv call in thread B crash
<Nova[m]>
shoot memory unsafety >:(
<mclasen>
and getenv is called e.g. by innocent looking things like _()
<Nova[m]>
so... shoot
<Nova[m]>
is there no good mechanism for this?
<Nova[m]>
i mean, aside from a portal that an app calls early that is
<Nova[m]>
wait but that wouldn't even work since you need a way to ID how the app launched...
<Nova[m]>
unless you piped your xdg activation token into the session portal and got back out a session restore ID
<Nova[m]>
but that's way to convoluted
<Nova[m]>
s/to/too/
<zamundaaa[m]>
You could use launch arguments
<zamundaaa[m]>
Like dolphin --xdg-session-restoration=id
<Nova[m]>
how is that supposed to be universal though?
<Nova[m]>
every app has its own way of parsing them
<mclasen>
you start to get an idea why xsmp failed...
<jadahl>
or 'platform-data' via D-Bus activation
<zamundaaa[m]>
Nova: if your goal is to have the app take part in session management, that's not an issue
<zamundaaa[m]>
or you could leave the "figure out if app is session-restoration-started" up to implementations
<Nova[m]>
yeah but there has to be a universal way to do this that doesn't screw up a whole area
<Nova[m]>
zamundaaa[m]: that'd be even worse
<Nova[m]>
jadahl: ooh what's this?
<zamundaaa[m]>
No, I'm saying that the compositor could check if some special process has started the app
<zamundaaa[m]>
And then tell the app through the protocol that it should restore its state with some session ID
Company has joined #wayland
<jadahl>
D-Bus activation is a way to "activate" a service/app by doing a dbus call, by starting or just calling a method. the method takes a 'platform-data' that is like an environment (a key-value dict where the value can be "any" data structure)
<Nova[m]>
zamundaaa[m]: how could it check?
<Nova[m]>
jadahl: how can you activate an app when it wasn't running like that?
<jadahl>
Nova[m]: they install a dbus activation service file that describes how to launch it
<davidre>
jadahl: that only works for apps that always have maximum one process
<zamundaaa[m]>
Nova: you have some sort of thing to start apps when the user is close to them in VR space, right?
<Nova[m]>
davidre: i will when monado implements spatial anchors
<jadahl>
davidre: can't there be a "outward facing" process that routes calls accordingly?
<jadahl>
Nova[m]: look in /usr/share/dbus-1/services/ for examples
<zamundaaa[m]>
You can have that thing signal the compositor through a special protocol about the app being started for example
<Nova[m]>
zamundaaa[m]: i will when monado implements spatial anchors
<Nova[m]>
for now i just launch all of them that were in a session
<davidre>
jadahl: maybe
<Nova[m]>
zamundaaa[m]: would it be early enough for the app to react and restore its state?
<bl4ckb0ne>
we don't have anchors?
<davidre>
But it means we would need to create such a router for every app that isn't dbus activatable right now
<davidre>
or a generic router maybe
<davidre>
no that woldnt work
<bl4ckb0ne>
Nova[m]: you need XR_HTC_anchor ?
<bl4ckb0ne>
or XR_MSFT_spatial_anchor
<Nova[m]>
bl4ckb0ne: that one
<bl4ckb0ne>
or XR_MSFT_spatial_anchor_persistence
<zamundaaa[m]>
Nova: if the toolkit supports it, sure. Apps could connect to the Wayland session and check for session restoration first thing when they start up
<Nova[m]>
no wait i was wrong
<Nova[m]>
XR_MSFT_spatial_anchor_persistence
<Nova[m]>
* `XR_MSFT_spatial_anchor_persistence`
<Nova[m]>
that's the one i need
<Nova[m]>
zamundaaa[m]: that's what worries me though, wayland might be started way later than the session would want to be restored for the app
<zamundaaa[m]>
The compositor is always started before apps
<Nova[m]>
i mean the wayland client
<Nova[m]>
s/client/socket connection in the app/
<zamundaaa[m]>
That's not how it works in the toolkits I know about
<Nova[m]>
oh, well that's good
<jadahl>
Nova[m]: the app that needs to talk to Wayland need to wait for the right systemd target before launching
<jadahl>
otherwise there is no guarantee it'll be able to connect
<Nova[m]>
jadahl: systemd target?
<kennylevinsen>
or be started by the wayland compositor/otherwise synchronized to only connect *after* the wayland server is running
<Nova[m]>
oh, well i can ensure that the wayland clients connect after the wayland server easily
<jadahl>
sure, either if the compositor is the process lifetime manager, then no issue. if you're using systemd to manager your processes, there is a target that the compositor will "call" to say its ready to receive clients, and apps that need a Wayland compositor must only start after this target
<Nova[m]>
sure, that's fine... but what about if an app connects to the compositor after it would have restored the state?
<Nova[m]>
s/the/its/
<davidre>
this would not happen
<davidre>
as the app needs to add new code for session restore
<davidre>
it can make sure it happens in the right order
<davidre>
or am I missing something
<jadahl>
I'm missing a lot of context fwiw :P
<Nova[m]>
idk i might just be catastrophizing
<Nova[m]>
davidre: except for the toolkits that do it
<Nova[m]>
* do it already
oliver has joined #wayland
<Nova[m]>
wait a moment how would the compositor even know which app is which
<Nova[m]>
s/which/the one to send the restore session ID to?/
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #wayland
junaid has quit [Quit: Lost terminal]
manuel1985 has quit [Ping timeout: 480 seconds]
<immibis>
session restore is not a wayland specific problem. a restored app can be connected to many servers, not just wayland. e.g. an IRC app must reconnect to servers and rejoin channels exactly the same as it must reconnect to the display server and recreate windows
Fxzx_mic has quit [Remote host closed the connection]
Fxzx_mic has joined #wayland
privacy has quit [Quit: Leaving]
mart has quit [Quit: Konversation terminated!]
kts has quit [Ping timeout: 480 seconds]
Fxzx_mic has quit [Remote host closed the connection]
<mclasen>
Reading the xdg-decoration spec, there seem to be copy-paste mistakes
<mclasen>
"After requesting a decoration mode, the compositor will respond by emitting an xdg_surface.configure event. The client should then update its content, drawing it without decorations if the received mode is server-side decorations. "
<mclasen>
that should probably xdg_toplevel_decoration.configure ?
<mclasen>
since the xdg_surface.configure doesn't let you receive a mode
<mclasen>
there's more like that. E.g. talk about configure_ack, when no such request exists in this protocol
fmuellner has quit [Ping timeout: 480 seconds]
<kennylevinsen>
I believe the intention is that zxdg_toplevel_decoration_v1::configure is sent during a xdg_surface::configure sequence (which is acked), but the wording does leave something to be desired...
<emersion>
xdg_toplevel_decoration.configure is always followed by xdg_surface.configure
<emersion>
clients shouldn't do anything in response to xdg_toplevel_decoration.configure, except update their pending state
<emersion>
specfcally, clients should redraw in response to xdg_surface.configure, not in response to xdg_toplevel_decoration.configure
<bwidawsk>
Yeah, I think it would be good if the spec was more explicit that xdg_surface.configure is the ultimate configure event of all configure events. Before emersion et. al pointed out the intent I didn't find the current verbiage clear: "The configure event marks the end of a configure sequence. A configure sequence is a set of one or more events configuring the state of the xdg_surface, including the final xdg_surface.configure
<bwidawsk>
event"
<bwidawsk>
Now that the intent is clear however, the verbiage seems fine... so /shrug
<mclasen>
if there was some conformance testsuite, maybe