Refuting the fallacious argument that rich Americans use to claim they are paying their fair share of income tax.

Highly progressive former state legislator Troy Jackson will replace Platner as candidate for senator from Maine.

The corrupter is trying to distract our attention from his attacks on the US election system using vague charges, based on inconclusive evidence, that China is doing such attacks.

US citizens: call on Congress to Abolish Super PACs.

US citizens: Join with this campaign to address this issue.

To phone your congresscritter about this, the main switchboard is +1-202-224-3121.

Please spread the word.

US citizens: call on the House of Representatives to vote to block 3.3 billion dollars in funds for Israel's military.

US citizens: Join with this campaign to address this issue.

To phone your congresscritter about this, the main switchboard is +1-202-224-3121.

Please spread the word.

US citizens: call on Maine AG to hold VICE accountable for murder.

"VICE" stands for Violent Institution for Contemptuous Execution.

See the instructions for how to sign this letter campaign without running any nonfree JavaScript code--not trivial, but not hard.

US citizens: call on your congresscritter and senators to pass the No Troops at the Polls Act.

See the instructions for how to sign this letter campaign without running any nonfree JavaScript code--not trivial, but not hard.

US citizens: Join with this campaign to address this issue.

To phone your congresscritter about this, the main switchboard is +1-202-224-3121.

Please spread the word.

US citizens: call on Congress to stop Trump from bullying states over elections.

US citizens: Encourage states to sue to stop the Paramount-Warner Bros Merger.

US citizens: call on McDonalds and other fast food giants to take responsibility for protecting their workers.

Trans community, allies condemn Wiener for exploiting a march he was asked to leave:

State Sen. Scott Wiener was not invited to the Trans March. He was really, really not invited: In fact, Gabriel Haaland, one of the founders of the march, told me, he had been asked specifically not to attend.

In 2016, then-Sup. Wiener, then-state-Sen. Mark Leno, and then-Mayor Ed Lee were booed off the stage at the march. (That was when Leno and Wiener were close, before Wiener stabbed his mentor in the back and endorsed London Breed for mayor.)

"We told them very clearly that we didn't want politicians in our space," Haaland explained to me. "We changed our policy because of Wiener, and his anti-tenant policies, and asked them not to come back." [...]

But Wiener didn't just show up; after he left, he used video of the event to raise national money, $127,000 in national money, for his Congressional campaign. (According to the Standard, even Netanyahu sided with Wiener, saying he was treated unfairly.)

"It's about as craven as I've ever seen," Haaland told me. "To use our community in this way to raise money is disgraceful. ... He never even picked up the phone and reached out to the Trans March folks." [...]

"The Harvey Milk LGBTQ Democratic Club condemns these self-serving actions by State Senator Wiener and urges politicians to stop using vulnerable communities as a fundraising tool. Trans people already face immense danger in this country. We need real allies, not people who will sell us out for a fundraising opportunity."

As of Tuesday, the van is back in action with a slightly different message: "I live in this van b/c Connie Chan hates housing."

Gazetteer SF learned that the registered owner of the van is being paid by a super PAC that supports Scott Wiener.

In April, the San Francisco Chronicle used California Department of Motor Vehicles data to identify Conor Johnston as the owner of the van. Johnston is a longtime Wiener supporter who served as chief of staff to London Breed when she was supervisor, and later advised her mayoral reelection campaign in 2024. He is also owner of the cannabis company Otter Brands, and has a history of political pranks and provocations.

Johnston and his business have been paid nearly $30,000 by the Families for an Affordable San Francisco super PAC this year, according to financial disclosures to the Federal Election Commission. Families is a super PAC founded by Wiener's active campaign director, Todd David, who remains the PAC's treasurer.

On April 28, the PAC paid Otter Brands, Johnston's cannabis company, $28,611.37 for "office consulting." One week later, the PAC paid $1,000 to Johnston directly for "office refurbishment." [...]

The Wiener campaign declined to comment through spokesperson Joe Arellano.

The Families PAC itself is a dark-money mess, as it leverages a 2024 FEC rule change in order for the PAC and Wiener's official campaign to share staff and coordinate canvassing operations together. In May, campaign finance experts told Gazetteer that the rule change represents a massive breach of a foundational policy to ban communication between a super PAC and a federal campaign on materials that advocate for voter action.

Previously, previously, previously.

While you (yes, you! no, not you, the one behind you) have been sweltering in the heatwaves of the northern hemispheres (Assisted-by: AI), I've been busy adding graphics tablet support to libei. This is scheduled for the soon to be released libei 1.7.0.

The initial work was done by Jason Gerecke and Josh Dickens from Wacom, I've been extending, polishing and testing it for the last few weeks.

Also, upfront: this only covers the stylus part of a tablet, we do not yet have an implementation for the "pad" part (the buttons, dials, rings, strips).

libei is, of course, the library for Emulated Input, a good-enough transport layer for sending logical input events between processes. We're already using libei as part of the XDG Portal Remote Desktop and Input Capture portals where we've been busy hurtling key and pointer events between the participating parties (and soon gesture events and text).

In the next release of libei, we will now also have "ei stylus" capabilities, i.e. the ability to send tablet stylus events. Getting pointer, keyboard and touch events supported was a long undertaking, everything was new and shiny and needed to be added everywhere in the stack. Now that all this is in place, scuffed and scratched, adding tablet events will be quite simple.

The ei stylus interface

Here's a short outline of how libei handles tablet events because it is, of course, different to how libinput handles them. Logical events are much nicer after all than physical hardware events.

First: we have a new interface: "ei_stylus". An EIS implementation (e.g. your compositor) may provide you, the libei client, with a device that supports this interface and one or more associated regions (typically representing the available screen areas). Typically this will be a separate device to the pointer devices or the keyboard devices but it's not a requirement. The ei_stylus interface comes with a bunch of capabilities you'd expect from a stylus (tilt, pressure, distance, ...) that you can selectively enable to emulate the stylus you want to. So basically, EIS will say "here's a stylus device, I support pressure, tilt, rotation, ..." and then the libei client says "This stylus should have pressure and tilt but nothing else". And then you do the normal thing: send proximity events, send tip down/up events, send data for the various capabilities you've enabled.

Happily for the EIS implementation, libei forces the client to take the guesswork out of everything: if you select the pressure capability, you must send a pressure value when coming into proximity. Where libei is used to forward data from a physical stylus (e.g. via some remoting protocol) it is up to the client to deal with firmware bugs that e.g. won't send data until a few frames in.

Note that there is no "tablet" anywhere. The tablet is represented by the region that the device may interact with. So in some ways every tablet is an on-screen tablet (which makes sense since we have logical events).

Multiple styli

The only quirky thing is how to request multiple styli[1]: libei 1.5.0 has added a "request device" request that allows a client to say "hey, EIS, I want a new device with capabilities pointer, keyboard, ...". And, if you've been a nice client, minding your own business, the EIS implementation may just create such a device for you.

So for the case of multiple styli: if the default stylus (if any) isn't good enough, you can now tell EIS that you want a(nother) device with stylus capability, configure the stylus capabilities once the device shows up and voila, you now have a normal pen, an art pen and maybe even an airbrush represented as logical device in libei. And since they're all separate devices in the protocol, they can be individually tracked and used, much like libinput tracks individual styli.

[1] For the "lots" of users that actually use multiple styli...

/me gestures vaguely at everything

Oh, hey, this works now? Great!

I'm not going to go too deeply into how pinch, swipe and hold gestures work, suffice to say we've had those in libinput (for touchpads) for years now so compositors and toolkits should already support those. And since libei and libinput have vaguely equivalent API layers integrating gestures for libei devices in compositors should be fairly straightforward.

The plumbing layers in the portals exist already too, so adding gestures to libei means that - once the compositors support it - we can have gestures support in remote desktop and input capture implementations without needing to update anything else. Hooray! Join in with me. Hooray! Louder! HOORAY!

For testing I had a (vibe-coded and thus immediately abandoned once testing was complete) gesturemouse utility which translates input events from a mouse into gesture events (depending which button is down). But don't let my lack of be a limit to your imagination, I'm sure you can come up with good use-cases for this.

If you've been paying attention (and I know you have, because it'd be embarrassing for you if you didn't) you'd have noticed that libei 1.6 (May 2026) added support for keysym and text events.

libei sends logical events between a libei client and an EIS implementation (typically: a Wayland compositor) but the keyboard interface it had was designed like real keyboards: key codes together with an (XKB) key map. You press one key, the keymap decides what that key means on the compositor side and off we go. This is easy but not always useful.

As of 1.6.0 libei now also supports an "ei_text" interface. A compositor may choose to provide you[0] with a device that supports this interface and that gives you two really nice opportunities.

First, you can now send a key sym. Instead of sending the KEY_Q key code and hoping it actually translates to 'q' (and if there's e.g. a frenchman^Wfrenchperson lurking behind the keyboard it may mean 'a'), you can now send 'q' as actual keysym. Or 'Q' instead of sending shift+q and hoping for no french influence in the process. It becomes the EIS implementation's job to handle that keysym - if it's a shortcut it may handle it directly, otherwise it may pass it on via Wayland to an application[1]. This centralises the keysym to keycode handling in the EIS implementation which is a pain for compositor authors (though they likely have that code already for e.g. RDP support) but reduces the variety of differently-wrong implementations in clients and of course makes it so much simpler to write clients.

Second, a client can send UTF-8 text to the compositor. So instead of emulating shift, keycodes, etc. you can literally send "Hello World" and expect the EIS implementation to pass that one. Again, makes a bunch of utilities a lot simpler to write and I mostly leave it up to your imagination to figure out what to do with that.

Notably for both cases: libei is about logical events that have a specific meaning that do not need further interpretation. If a client sends 'Q' that means it is supposed to be an uppercase Q. Sending keysym Shift_L and Q makes little sense. And for the utf8 text events: how the text comes to be matters doesn't matter for libei so you may use an IM to make up the text to begin with and send it, once committed, to EIS. It's not for sending partial strings.

As mentioned in the previous post: the plumbing for this is already in place so both clients and compositors can add support for this new interface without having to bother the rest of the stack (e.g. portals). So, hooray I guess.

The text/keysym support is relatively recent so expect this to hit the next compositor version (or the one after that).

[0]: the EIS implementation decides which devices are available and arguing about this is even less useful than arguing with a world cup ref
[1]: after converting it to a key code with possible keymap changes... but hey, such is life

Turns out it's been years since I've talked about eggs, so let's change this. libei is, of course, the library for Emulated Input[1].

This post is mostly a refresher because it's been so long and a short summary of some of the work we've done so far, in preparation for some more posts that come soon.

libei is a transport layer for logical input events, unlike libinput which is a hardware abstraction layer. In libinput's case the device's firmare/kernel pass events that are somewhere on the sanity spectrum, libinput tries to make sense of those and then we convert those to logical events to be consumed by the next layer (typically the Wayland compositor or Xorg). This is how e.g. "touch down at position x1/y1, touch up at position x1/y2" is converted into a button click event if touchpad tapping is enabled. Or maybe into nothing if we find it was an accidental palm touch.

libei works purely on the logical level - you as the libei client pass logical events to the EIS (Emulated Input Server) implementation (typically the compositor). No guesswork, you say button click, EIS gets a button click. libei supports a "sender" and "receiver" mode, depending on whether events are sent to the EIS implementation (input emulation) or receive from the EIS implementation (input capture). libei is designed for the Wayland stack but there are zero requirements for Wayland on either the client or the EIS implementation.

Core to libei's design is that the EIS implementation is in control of virtually everything, it decides which devices are available to the client, when those devices can send events, etc. Much like the compositor is in charge when it comes to physical devices - if a compositor decides a physical device doesn't exist, a Wayland client cannot get events from it.

Since the original proposal (again, [1]!) we've been busy bees and libei is now a part of the XDG Remote Desktop portal and the XDG Input Capture (both since version 1.17, mid 2023). In both cases the portal is for the negotiation and initial agreement of what should happen, libei is then used as the transport layer between the two processes [2].

More recently we also added session persistence support so you don't have to allow access on every connecton. Much of the work enabling this was done by Jonas Ådahl, it is now in the portals since version 1.21.0 and should be in the major compositors in the current or next versions.

Plumbing the Pipes

Getting all this into place was a huge amount of work across several pieces of the stack. This isn't exciting in the same way as laying plumbing pipes isn't particularly exciting but much like regular plumbing: once it's in place you can change your diet without severely impacting everyone again. Try get that analogy out of your head now. You're welcome.

In libei's case this means three things:

• if you have a client that uses the XDG portals to send/receive events they will now work with any compositor that implements the portal. No need for GNOME/KDE/... specific APIs.
• if you have a compositor that implements EIS you have all the infrastructure in place to talk to libei clients from somewhere else, if need be. The use-cases for this aren't fully scoped yet (assisitive technologies, virtual keyboards, touchpads, etc?) but the piping is there and ready to be (ab)used .
• since the actual events back and forth don't affect the layers in between, we can now add new events to libei without having to change everything else again.

The XWayland XTEST use-case

An example for such a case where we can now abuse the piping is Xwayland support for XTEST. XTEST is the protocol that everyone uses to emulate input under X but in Wayland it's not hooked up to anything so those APIs simply won't work.

But what we can do in Xwayland is translate XTEST to libei events and facilitate the portal interaction. This means our stack looks roughly like this:

    +--------------------+             +------------------+
    | Wayland compositor |---wayland---| Wayland client B |
    +--------------------+\            +------------------+
    | libinput |   EIS   | \_wayland______
    +----------+---------+                \
        |          |           +-------+------------------+
 /dev/input/       +-----------| libei |     XWayland     |
                               +-------+------------------+
                                                |
                                                | XTEST
                                                |
                                         +-----------+
                                         |  X client |
                                         +-----------+

What's next

So we have a lot of the plumbing in place, or in another anology: we have a hammer, let's go looking for nails. And right now the nails we can see are sending text, gestures, and tablet support. And those will be the subject of the next few posts.

[1]: 6 years ago?! whoah...
[2]: in Remote Desktop's case replacing the DBus emulation APIs which were a Newton's Cradle of wakeups for at least 4 processes per event

Sadly, the Gakken World Eye is now going for almost a grand on eBay.

So I bought the cheapest desktop video projector I could find ($30) just to see if I could aim that at the inside of the dome. Unsurprisingly, the answer is no. That projector needs to be about 2½ feet behind the dome to fill it and be in focus, which is less of an eyeball and more of an eye sausage.

I took both apart and they have very different projectors and optics, so just swapping lenses isn't an option.

I suspect that in principle I could put some extra lenses in front of this thing to make it go but I have no idea how to do that.

So. Got a Gakken World Eye that you'd like to donate to the cause of "weird DNA Pizza decor"? Or, do you know of a desktop video projector that can throw an in focus 10" tall image from a distance of 10" to 20"?

Previously, previously.

remove_filter ('wp_head', 'rest_output_link_wp_head'); remove_filter ('template_redirect', 'rest_output_link_header', 11); remove_filter ('wp_head', 'wp_oembed_add_discovery_links'); remove_filter ('wp_head', 'wp_oembed_add_host_js'); add_filter ('json_enabled', '__return_false'); add_filter ('json_jsonp_enabled', '__return_false'); add_filter ('xmlrpc_enabled', '__return_false'); add_filter ('rest_url', 'jwz_no_rest', 1, 4); add_filter ('rest_url_prefix', 'jwz_no_rest', 1, 1); function jwz_no_rest ($url, $path='', $blog_id='', $scheme='') { return ''; } add_filter ('rest_authentication_errors', function ($result) { return new WP_Error ('Fuck REST', 'Fuck REST', array ('status' => 403)); }); // And for good measure: add_filter ('wp_supports_ai', '__return_false');

Previously, previously, previously, previously.

"Build history as you grow: Once you have enough history, we'll automatically unlock features." Apparently my 14+ year old youtube channel has not yet reached 2 months of active use, according to the vibe-coded math of Google's robots.

Since, as you know, arguing with robots is something of a hobby of mine, I uploaded my traditional driver's license. You can't just "upload" it, of course, they require you to scan a QR code with a phone and take a photo from within the browser, for maximal tracking. So I used one of my burner phones for that. They say their response takes 24 hours, so presumably some dollar-a-day call-center gig worker in India is going to put eyeballs on it, so we'll see how that goes.

In case you're wondering what stupidity I'm up to this time:

Bonnie Tyler died last week, and so the glorious "Total Eclipse of the Heart, Literal Version" by Persephone Maewyn and dascottjr was making the rounds again, dodging takedowns. (This video is a textbook case of fair use, since not only is it a parody song, but the lyrics are direct commentary on the video itself, I mean come on.) Anyway all extant copies of it are shit quality, so I reconstructed it from the official HD video plus the "literal" audio, and re-built the subtitles by hand. Immediate takedown. I appealed. A week later, some intern or chatbot at BMG said "fuck you no". Now I'm trying to counter-claim.

Anyway, maybe someday you'll get to see this higher quality version of the video. It's still pretty funny. You can go request it on the DNA Pizza music video stream I guess.

Update: Oh no. Anyway

Date: Fri, 17 Jul 2026 02:28:12 -0700
Subject: Your YouTube ID verification was unsuccessful
From: YouTube <youtube-noreply@google.com>
To: jwz@jwz.org

Your YouTube ID verification was unsuccessful

Your ID verification was denied

Google couldn't approve your ID verification. You can try again to get advanced YouTube features with your ID or video verification in 30 days. In the meantime, you can continue to build your channel history by uploading videos or live streams and following YouTube's Community Guidelines. After 30 days, this history may help you get access to advanced YouTube features. Learn more