DEV Community: Michael Jordan

It Started with Fonts: The Nearly Three-Month Road to Selling My Software

Michael Jordan — Mon, 12 Oct 2026 17:09:25 +0000

I've been writing code of one sort or another, as a hobbyist or professionally, for over half a century.

Some of my projects have involved years of work. The one I'm now trying to take to market started with fonts.

Fonts are one of those things we take for granted every day. My studies of them eventually grew into a .NET NuGet package anyone can download and use: Lxman.PdfLibrary.

I started it well before AI coding assistants were a thing. Towards the end, though, I certainly used AI to help me through the maze of transforms, matrix manipulation, and other technicalities involved in faithful document reproduction.

I've always had it in the back of my mind to release some of my work for others to use. After developing the library, I decided to build a closed-source product based on it. That became Pellucid, a PDF editor, which I've recently set up on my store.

I naively thought bringing a product to market meant building something good, putting together a little website, adding a way to take payments, and going to market.

This is the story of what that actually involved.

July: making it a company

On July 10, 2026, I submitted the paperwork to form an LLC in North Carolina. Pellucid launched on October 6.

Nearly three months between those two events, on top of the years of development that came before them.

That wasn't three months spent waiting for the state, or the bank, or a payment provider. There was development and testing going on too. But there was also a collection of business tasks that I'd badly underestimated, and several points where progress depended on someone else's approval.

The state formally filed the company on July 22, twelve days after I submitted the paperwork. By August 2, I had the stamped articles in my records.

Even here, there was a distinction to get right. The day I submitted the application wasn't the day the company legally came into existence. I'd initially treated the submission date as the formation date. The stamped paperwork corrected that.

Meanwhile, I was sorting out the product name. I went through seven candidates before settling on Pellucid. I'd already bought a domain for an earlier choice, then dropped that name after looking more closely at potential trademark conflicts.

These were preliminary checks, not a guarantee that a name was legally clear. They were enough to make me reconsider the first choice.

So there I was, dealing with formation dates, an operating agreement, domain names, and trademark research for something that had started with fonts.

August: a tax ID and a business checking account

On August 10, I obtained the company's EIN through the IRS online system and opened a business checking account.

Both happened that day. The bank approved the application the same day I applied, so I can't blame the bank for dragging that part out.

But a month had already passed since I'd submitted the state paperwork. The business now had its formation documents, a federal tax ID, and somewhere to keep its money separate from mine.

It also needed books. There were expenses to record, personal money put into the business to account for, and records to keep. Buying something for a project and recording it properly as a business transaction are separate tasks.

None of this added a feature to the PDF editor. It was still work that came with selling it.

There was another identity to sort out

Distributing a desktop application under a company name brought another set of requirements.

For Apple's organization enrollment, I needed a D-U-N-S number. On August 21, I located an existing record for the company. I didn't have to request a new one, but it was another piece of business identity to find and check.

Having an individual developer account and having an account under the company weren't the same thing. Later, on September 24, I requested the conversion of my personal Apple developer account to the company.

At that point, the conversion was in progress with no ETA. It was confirmed complete on September 29.

That settled the account conversion. Certificates, signing, notarization, and testing the actual customer packages were still separate work. An approved company account didn't turn a local build into a finished Mac release by itself.

September: adding a way to take payments

This was the part I'd mentally reduced to a small item on the list.

On September 21, I set up the company domain, business email, and company website. I also created the Lemon Squeezy store and completed its onboarding application.

Even the email setup had its own details: DNS records, email authentication, and checking that messages actually arrived and went out under the right address.

I chose Lemon Squeezy as the merchant of record. It handles customer payments and sales tax, then remits payouts to the business. That takes a substantial piece of the selling process off my hands. It doesn't remove the onboarding process.

After submitting the application, the store remained in test mode while it was reviewed.

I could work on the integration and test purchases, activation, and refunds. Being able to run those tests didn't mean I was approved to take real payments.

Lemon Squeezy requested a demonstration and more information. I submitted those on September 25. By September 28, merchant approval was confirmed.

A week from onboarding to confirmed approval isn't an extraordinary delay on its own. By then, though, it was late September, and I'd started the company paperwork in July. Each individual step looks fairly small when you describe it separately. Together they occupied a much larger stretch of the calendar than I'd pictured.

Approval wasn't the end of the list

Once the merchant account was approved, there was still a live product to configure and a customer purchase to fulfill.

A payment had to result in a usable license. A customer had to receive the right download, install it, and activate it. Refunds had to behave properly. There needed to be a way to deal with someone replacing a computer or losing access to a device.

There were decisions about refund terms, license coverage, and support. Those decisions then had to agree with what the website said and what the software actually did.

Test mode was useful, but a successful test purchase wasn't the same as verifying the live customer path. The packages being delivered needed to be the ones that had actually been checked, signed where appropriate, and accepted for release.

This is where the business work came back around to software engineering. There was more code and testing, but now it was about the machinery around the application as well as the application itself.

October: finally available

Pellucid launched on October 6 for Windows, macOS, and Linux.

From July 10 to October 6 was 88 days.

That number describes my journey, not a required waiting period for anyone else's business. Some tasks could overlap. Some happened quickly. Some required review. Software work continued alongside all of it.

What I'd underestimated was the total. Form the company. Check the name. Get the tax ID. Open the account. Keep the books. Establish the business email and website. Apply to the payment provider. Supply the demonstration. Sort out the developer account. Sign the releases. Verify that a purchase actually gives the customer something they can use.

I'd thought about most of those things, if at all, as small jobs to take care of once the software was ready.

They took nearly three months of calendar time to come together.

What I'd tell another developer

If you're planning to sell something you've built, investigate the business and distribution requirements while you're still developing it. Find out which accounts require a legal entity, what evidence the providers want, and which steps have a review process.

Keep the dates and confirmations. In my case, even the formation date needed correcting once the stamped document arrived.

And give the work between approvals a place in your schedule. Getting approved to accept payments still leaves you responsible for delivering the software and supporting the person who bought it.

After more than half a century of writing code, I still had plenty to learn about getting my own product to market.

It started with fonts. I hadn't expected the journey to include quite so much paperwork.

I'm the developer of Pellucid and the open-source .NET library Lxman.PdfLibrary that it builds on.

Reverse-engineering the OBSBOT Tail 2: HTTP, USB, and a Linux kernel fix

Michael Jordan — Sat, 03 Oct 2026 01:35:51 +0000

The first OBSBOT camera I reverse-engineered was a Tiny 2: a webcam on a motorized gimbal. I built obsbot-mcp so an AI assistant could take a picture, inspect it, and control the camera through the Model Context Protocol.

Then I started on the Tail 2.

Same manufacturer. Similar controls. Even the same USB Extension Unit GUID. Plenty of reasons to expect that supporting it would mean adding another device ID and adjusting some ranges.

The Tail 2 has a different network protocol, a different vendor USB protocol, and the same firmware capability-reporting problem that had sent me into the Linux camera driver. The useful part of the investigation was working out which similarities were real.

The measurements below were made on a physical Tail 2 in September 2026, with firmware 7.2.13.1. The protocol notebook distinguishes hardware measurements from things inferred by reading the camera's software.

The camera ships its own API client

The Tail 2 is a network PTZ camera with Ethernet, Wi-Fi, streaming outputs, and a USB-C webcam mode. Point a browser at its network address and it serves a web application.

That application was the best starting point. Its minified Vue/Vite bundle contained the endpoint names, request methods, and payload construction for an HTTP API under /camera/sdk/.

For example, these are useful read-only probes. Set CAMERA to your camera's address:

CAMERA=192.168.1.50

curl "http://$CAMERA/camera/sdk/device_info"
curl "http://$CAMERA/camera/sdk/range"
curl "http://$CAMERA/camera/sdk/ptz/zoom"

The range endpoint reports the camera's own zoom-ratio scale, 1.0–12.0. Setting zoom requires both a ratio and a speed:

PUT /camera/sdk/ptz/zoom
Content-Type: application/json

{"ratio": 2.0, "speed": 5}

Leave either field out and the camera returns 400. That is a small detail, but exactly the kind that makes an undocumented API frustrating when all you have is an endpoint name.

The bundle gave me a census of 47 endpoints. That does not mean 47 fully decoded, hardware-verified operations: some payloads remain unprobed. It gave me a map of where to look.

On the tested configuration, HTTP reads and writes worked without authentication. That is an observed property of this unit and firmware, not something I would generalize to every configuration or future release.

A successful request can change nothing

The camera also pushes a JSON status block over:

ws://<camera-address>/ws/

Connect, and a full status message arrives without a subscription request. Further updates arrive at roughly one per second. The block includes zoom, tracking mode, orientation, presets, streaming flags, battery state, and subsystem health.

That feedback matters because the write response is weaker than it looks:

{"code": 200, "err_idx": 0}

During testing, a roll-trim write received that response while the portrait-rotation motor was moving. The requested value never landed. Reading it back still showed the old value.

So the client separates acknowledgement from observed state. Where feedback exists, it sends the command, polls a bounded number of times, and returns the value it actually read plus a settled flag.

The zoom implementation, for example, compares the reported ratio with the target within a small tolerance. Portrait rotation checks the orientation field in the WebSocket status. If the polling budget runs out, settled:false says exactly what happened: the command was sent, but the expected state was not observed in time.

There are limits to this verification. The network status block has no live yaw or pitch. Recenter therefore returns on acknowledgement; it cannot prove physical arrival. Preset recall can verify zoom, but that does not prove that both gimbal axes have arrived.

That distinction matters when the caller is an AI assistant. A tool result saying “done” becomes the premise for its next action.

Presets: the request schema was in the component

My first attempts at the preset endpoint failed because I guessed the discriminator wrong. action, type, and operate were plausible. The firmware wanted operation.

Reading the web application's preset component gave me this grammar:

PUT /camera/sdk/ptz/preset

{"operation":"set",    "id":0, "name":"RGVzaw=="}
{"operation":"call",   "id":0}
{"operation":"rename", "id":0, "name":"V2lkZQ=="}
{"operation":"delete", "id":0}

Names are base64-encoded UTF-8. IDs are zero-based, with three slots. All four operations were exercised on hardware.

The semantic detail is more important than the spelling: set saves the camera's current pose. It also overwrites an occupied slot. There is no decoded request here that accepts an arbitrary yaw/pitch pose to save.

Reading a preset returns angles and a zoom ratio, but a rich response schema does not imply a symmetric write schema. You cannot take the returned object, edit its angles, and assume that writing it back will position the camera.

The server exposes slots as 1–3 and handles the wire encoding internally. Its save verification checks that the slot exists afterward; it cannot independently verify the captured pose, and an existing slot alone does not prove an overwrite succeeded.

Getting a picture took a different protocol

Controlling a camera and getting video from it turned out to be separate jobs.

The device advertised RTSP, and its status could report RTSP enabled. Nevertheless, the paths I tested returned 400 Bad Request, including after a reboot with the enable flag set. I did not establish a working RTSP stream on this firmware.

SRT listener mode worked. With that output enabled in OBSBOT Center, an SRT-enabled ffmpeg build could pull a frame:

ffmpeg \
  -i "srt://$CAMERA:5000?mode=caller&latency=120&streamid=mainstream" \
  -frames:v 1 tail2.jpg

That uses the measured port and default stream ID. The tested stream was H.264 at 1920×1080, 30 fps, with AAC audio.

Two practical constraints remain: enabling SRT disables NDI on this configuration, and the SRT enable state does not survive a camera reboot. Center also requires the output to be off while changing its streaming settings. An early apparent startup delay was actually a probe landing during that reconfiguration window; once enabled, the listener served immediately.

The snapshot tool uses this SRT path. The camera-control module is pure TypeScript, but image capture still needs ffmpeg.

The same USB GUID did not mean the same protocol

The USB side supplied the most misleading resemblance.

In UVC webcam mode, the Tail 2 exposes the same vendor Extension Unit GUID as the Tiny 2. Its selector 6 also returns a 60-byte status block. Running the Tiny 2 decoder over those bytes produces plausible-looking values.

They are wrong. Some byte positions happen to line up; the layouts are different.

The useful method was to change one setting at the camera, read the selectors again, and compare. Then write values the camera had actually been observed to report and check the result.

The Tail 2 controls I decoded use flat, zero-padded 60-byte payloads. They do not need the Tiny 2's framed V3 command, sequence number, or CRC.

Selector 9 controls human tracking:

First byte	Observed meaning
`00`	Tracking off
`01`	Human tracking, single
`02`	Human tracking, group

Those values were written and read back on Linux. Activation also depended on a matching subject being in frame: an accepted write did not necessarily make tracking engage.

Selector 10 contains another easy trap. Its read layout is a settings block, but its write layout is an index/value pair:

Read:
  byte 0 = tracking speed
  byte 2 = Auto Zoom level

Write, with the remaining bytes zero-padded:
  00 04 = set tracking-speed index 0 to value 4
  02 07 = set Auto Zoom index 2 to value 7

Writing a read block back verbatim changes the wrong thing. A payload beginning 02 01 07 means “set index 2 to value 1,” regardless of what its third byte meant in the read response.

The camera even keeps these settings separately for landscape and portrait orientation. Switching orientation and seeing different values was not evidence that the preceding write had disappeared.

These USB findings are documented, but the current Tail 2 MCP tools use the network transport. A combined USB/network implementation is still future work.

The Linux problem really was shared

Standard UVC pan, tilt, and zoom controls also work on the Tail 2. On Linux, however, the affected controls had the same capability-reporting defect as the Tiny 2:

GET_INFO -> 0x03
            GET and SET supported
            AUTOUPDATE not advertised

The camera can return changing PTZ values through GET_CUR, including motion driven by its own tracking. But its capability reply causes uvcvideo to clear the auto-update flag and cache those readings.

This is also where I need to correct my earlier Tiny 2 article.

I had argued that even a compliant camera would yield only one live sample per write. That explanation was wrong. Ricardo Ribalda pointed out the read-side rollback path I had missed. At the end of a read transaction, the driver invalidates an AUTO_UPDATE control's cache, allowing the next read to fetch from the device. It does not need a control-change interrupt between every pair of polls.

Restoring the existing flag is sufficient. A separate live-read buffer was unnecessary. A wider probe also disproved my earlier claim that the firmware returned a uniform 0x03 stub for every control: the response varies; the affected PTZ capability bits are wrong.

The userspace write lesson survived review: set pan and tilt together in one VIDIOC_S_EXT_CTRLS call. Both axes share one UVC payload. If separate writes merge against live position while the first axis is still moving, the second write can replace the first axis's target with an intermediate position.

On September 29, Hans de Goede merged the fixup infrastructure and both camera entries into the uvcvideo maintainer's for-next branch. The Tail 2 entry is commit 7a7c915d6bae.

That is a maintainer-tree merge. It does not establish availability in a released or distribution kernel. At the September 29 checkpoint, the separate v5 patch exposing volatile-control flags with corrected event handling was still under review. The fixups already provide live reads without that separate patch.

The updated kernel write-up records the mechanism, review corrections, and hardware results.

What is usable now

The Tail 2 module in obsbot-mcp exposes 16 tools covering discovery, status, device information, zoom, recentering, portrait rotation, roll trim, tracking mode and speed, five preset operations, and snapshots.

For network discovery, call obsbot_tail2_scan, configure OBSBOT_TAIL2_HOSTS, or pass the camera's IP as the camera parameter. Registered cameras can also be selected by MAC address or device name.

The HTTP/WebSocket control implementation is shared across Windows, Linux, and macOS, with no platform-specific native helper. The USB kernel fixups are a separate result of the investigation; those network tools do not require them.

Arbitrary network yaw/pitch commands, live network pose feedback, and a shipped Tail 2 USB transport remain gaps. The Tiny 2's “point at this pixel” workflow should not be assumed to work on the Tail 2 just because both cameras appear in the same project.

The recurring lesson was that decoding a payload is only the beginning. A response can acknowledge a write that never happened. A status block can omit the one measurement needed to verify arrival. Two devices can share a GUID while speaking different protocols. And a convincing explanation of a driver can still be missing the function that changes the conclusion.

The useful API is the one that preserves those distinctions all the way up to the caller.

Micro-compaction: amortizing context compression in agent loops

Michael Jordan — Wed, 05 Aug 2026 16:26:59 +0000

If you've run a long agent session in any framework, you've hit the wall: context fills up, the framework decides it's time to compact, and everything stops while a summarizer chews through the whole transcript. In hermes-agent that batch compaction fires around 80% of the context threshold, and on a long session the pause is measured in minutes. The agent isn't stuck, it's doing necessary work, but from the outside it looks dead. And the longer you wait to compact, the bigger the lump you eventually pay.

Micro-compaction is a different way to pay the same bill. Instead of one big batch pass when you're nearly full, you fold the oldest un-absorbed exchange into a rolling summary after every turn. The total summarization work is roughly the same. What changes is the shape of the cost: small increments spread across the session instead of one long stall at the worst possible moment.

Origin note, since it's unusual: the first draft of this feature was written by Hermes itself, for its own codebase. What follows, the measurement, the bugs, and the upstreaming, is what it took to get that draft into a state worth merging.

How it works

After each turn, the finalizer looks for the oldest agent turn that hasn't been absorbed yet, summarizes it into a cumulative rolling summary, and splices a single summary marker into the transcript where that material used to be. There's exactly one marker at any time. Each pass replaces it rather than adding another. A protected head (the system prompt and early setup) and a protected tail (the most recent turns, 16% of the window by default) never get touched, so the model always has verbatim access to what it's currently working on.

One design decision worth calling out: user turns are never compacted. Assistant output compresses well because it boils down to "it did it this way," and the details can usually be reconstructed from the work that followed. User intent can't. If you summarize away what the user actually asked for, no amount of downstream context recovers it. The cost is a floor on how much the middle of a conversation can shrink, since user messages accumulate verbatim. I think that's the right trade. If a user is dropping 20K-token prompts, that's on them.

The feature is opt-in:

compression:
  micro_compact: true

There's also micro_compact_every_n_turns if you want to thin out how often it runs.

What the numbers say

The claim isn't "saves tokens." Early on I framed it that way and it was the wrong headline. The real value is two things: the long pause gets amortized away, and context lasts longer before you hit the threshold at all.

The validation run was a real 3.5-hour session, a whole-project code review, with telemetry on every pass. Two results:

Zero batch compactions across roughly 75K tokens of transcript. The multi-minute pause never fired once.

Occupancy (context used as a share of the compaction threshold) went 8.7% → 15.0% → 17.5% → 21.8% → 22.0%, then flat. In the last stretch the conversation added 4,841 tokens and micro-compaction reclaimed 4,395. That's equilibrium at 22% instead of a steady climb toward 80%. The session could have run much longer than it did.

One gotcha if you instrument this yourself: the first pass costs tokens. The summary marker carries about 411 tokens of fixed scaffolding, and on pass one that's charged against a single absorbed exchange, so the delta is typically positive, around +330 in my measurements. From pass two the marker is replaced instead of added and each exchange is near-pure saving. Break-even lands around pass two or three. Judge the trajectory, never a single telemetry line.

Getting to trustworthy numbers was most of the work, honestly. The original draft had a bug where every pass appended a new marker and left the old ones in place. The rolling summary is cumulative, so each stale marker was a near-duplicate prefix of the next, and the transcript grew every turn. Measured over six turns: 4,104 tokens ballooned to 4,797. With the supersede fix, the same conversation went 4,104 to 2,572. A second bug had the resume cursor pointing at pre-splice indices, so on tool-heavy conversations it silently skipped about half the exchanges it should have absorbed. Neither bug is visible in a single-pass unit test. Both fell out of a randomized stress harness that runs 480 conversation shapes through 25 passes each and asserts invariants after every pass: one marker max, transcript stays API-valid, message count never grows, user turns intact. If you're building anything in this class, compaction bugs are accumulating drift, and simulating many turns is the only test shape that finds them.

The honest costs

Micro-compaction rewrites already-sent history every time it commits a pass, and that breaks the provider's prompt-cache prefix. Batch compaction breaks it too, but once, not every turn. hermes-agent's own config treats per-conversation caching as close to sacred, and its proactive-prune logic exists specifically to avoid "a tiny break every tool iteration." Micro-compaction as originally shipped was doing exactly that, which is why review flipped it to default-off. If your provider bills cache reads at a steep discount, per-turn invalidation is real money, and my 3.5-hour validation measured occupancy and pause counts but never priced the cache side. That tradeoff is not settled by my own numbers, and I'd rather say so than pretend the headline result covers it.

The passes themselves aren't free either. Median pass duration in the validation run was about 31 seconds, synchronous in turn finalization. The response has already streamed by then, so the user isn't staring at a frozen answer, but the turn doesn't close until the pass does. Total was around two minutes of summarization spread over 3.5 hours, which still beats one multi-minute lump, but 31-second increments strain the "small increments" framing. In my setup the bottleneck is the summarizer model, a 4-bit Qwen 7B on a shared box, not the input size, so a faster auxiliary model would probably shrink this a lot. Probably.

There's also no reclaim-size gate yet. A pass commits whatever one exchange saved, even if that's a few hundred tokens, and each commit is a cache break. The obvious follow-up is buffering absorbed exchanges and only splicing once the reclaim crosses a threshold, mirroring what the prune logic already does. That doesn't exist today.

Where it landed

The feature merged into hermes-agent and ships in v0.19.1, opt-in via the config flag above. The original PR was #74522; it landed through a maintainer salvage PR (#75345) that kept the commits and authorship and then reworked some internals with a design I'd call better than mine in places. The marker is now an assistant-role message, an exchange is a full agent turn bounded by user messages, and markers are only ever superseded when their content is provably contained in the rolling summary, which makes stale-marker bugs structurally hard to reintroduce. The docs in the repo cover the mechanics in more depth.

If you maintain an agent loop and batch compaction pauses are hurting you, the shape of this idea transfers even if the code doesn't: pay the summarization bill per-turn, protect the head and tail, never touch user intent, and instrument it before you trust it. Especially that last one. Every real bug in this feature was found by measurement, not by reading the code.

I reverse-engineered a webcam so Claude could point it at things

Michael Jordan — Tue, 04 Aug 2026 20:39:26 +0000

The OBSBOT Tiny 2 is a webcam bolted to a motorized gimbal. It pans, it tilts, it zooms, and it has an on-device AI that follows you around the room. It's a nice piece of hardware and OBSBOT ships a perfectly good GUI for it.

What I wanted was different. I wanted an MCP server, so a model could take a snapshot, look at the picture, find the thing it cared about, and then point the camera at it. Close the loop: see, aim, see again.

That needs a protocol. There isn't a published one.

Ghidra, headless

The vendor app knows how to talk to the camera, so the protocol is in the vendor app. I ran Ghidra headless over the binaries and went looking for whatever assembles the USB control transfers.

It's a class called FrmPacketV3, and once you find it the frame is almost tidy:

off 0    : 0xAA              magic
off 1    : 0x25              flags (bit 0x60 => there's a nested segment)
off 2-3  : seq    u16 LE
off 4-5  : len    u16 LE     bytes covered by the checksum (12)
off 6-7  : token  u16 LE     the checksum itself
off 8    : sender   0x0A
off 9    : receiver 0x04
off 10-11: cmd    u16 LE     the command id
off 12+  : payload           float32/int32, little-endian

Sixty bytes, zero-padded, handed to a UVC Extension Unit as a SET_CUR on selector 2. The token is CRC-16/USB — poly 0xA001, init 0xFFFF, reflected, xorout 0xFFFF — computed over the first twelve bytes with the token field itself zeroed:

def token(data: bytes) -> int:
    crc = 0xFFFF
    for b in data:
        crc ^= b
        for _ in range(8):
            crc = (crc >> 1) ^ 0xA001 if crc & 1 else crc >> 1
    return crc ^ 0xFFFF

Gimbal moves don't fit in twelve bytes, so they go in a nested segment starting at offset 12 with its own length and its own CRC over its own bytes. Roll, pitch, yaw as three float32s. A move-to-angle is cmd = 0x6444, a speed move is 0x6484, wake and sleep are both 0xA0C2 with an inverted flag byte (wake is 0, sleep is 1, which I got backwards the first time).

There turned out to be four separate ways into the device, and the vendor app uses all of them depending on what it's doing: framed V3 packets on XU selector 2, flat byte reads on XU selector 6, and then plain IAMCameraControl and IAMVideoProcAmp for the boring stuff. Knowing which channel a given feature lives on is most of the work.

The bug that taught me not to trust my own opcode table

Track speed didn't work. I'd send the command, the camera would acknowledge nothing in particular, and the tracking speed would stay exactly where it was. For weeks I assumed I had the payload encoding wrong, because that's the kind of thing that's usually wrong.

I had 0x0944. The real opcode is 0x0cc4, AI_SET_TRACK_MODE. I only found it by capturing USB traffic while OBSBOT's own app changed the setting, and diffing that frame against mine.

This is the thing about an undocumented binary protocol that I hadn't internalized: a wrong opcode doesn't fail. There's no error, no stall, no NAK. The firmware looks at a command id it doesn't recognize and drops it on the floor, and from the host side that's indistinguishable from a command that worked and had no visible effect. Every silent no-op I chased after that, I went to the wire first instead of re-reading my decoder.

Static analysis tells you what the code could send. A capture tells you what it does send. Those are different documents.

Then half of it turned out not to be vendor protocol at all

Somewhere in the middle of this I checked whether the gimbal answers CT_PANTILT_ABSOLUTE — control selector 0x0D, a bog-standard UVC Camera Terminal control that every OS already knows how to talk to.

It does. And it's not echoing back what I told it. I polled it every 40 ms while a 0° to 90° pan was in flight:

t+0ms     pan=0°
t+709ms   pan=3°
t+832ms   pan=10°
t+1913ms  pan=51°
t+3259ms  pan=90°   <- physical arrival
t+3300ms  pan=90°   (steady)

That's an encoder tracking a physical slew. Tilt stayed at zero the whole time, having never been commanded. It even reports motion the host never commanded through that control at all — vendor speed moves, recenters, the AI panning itself around after a face.

That reframed the project. My end goal was cross-platform, and vendor XU access means writing and maintaining a native helper for every OS — DirectShow on Windows, IOKit on macOS, V4L2 and libusb on Linux — and then keeping three implementations of the same protocol honest against each other. Standard UVC controls cost none of that. The OS already has the code.

So the rule became: use standard UVC wherever it's sufficient, drop to the vendor extension unit only where it isn't. Zoom is UVC. Focus, exposure, white balance are UVC. Pan and tilt are UVC in both directions, read and write. What's genuinely vendor-only is the AI tracking, the presets, sleep/wake, and speed-mode gimbal moves. That's maybe a third of the surface, and everything else stopped being three implementations.

And it worked everywhere except Linux

Same control, same camera, same USB transfers. On Linux, pan_absolute reads back whatever value I last wrote, forever, no matter where the gimbal actually is.

That's uvcvideo caching. __uvc_ctrl_load_cur() short-circuits on a ctrl->loaded flag, and that flag gets cleared in exactly two places: the driver's own commit path, and on receipt of a Control Change interrupt from the device. The Tiny 2 never sends one. I dumped GET_INFO across five Camera Terminal controls and got a constant 0x03 for every single one — the firmware isn't computing the response per-control, it's returning a stub. Bits D3 (Autoupdate) and D4 (Asynchronous) are clear on a gimbal that takes seconds to complete a move and repositions itself autonomously as a headline feature. Both should be set. That's a real spec violation, and I've now reported it to OBSBOT.

But "the vendor is non-compliant, work around it" is a weak argument to bring to a kernel mailing list, and it's also not what's actually going on. Trace the cache on a fully compliant PTZ camera, one that does set D3 and does send its interrupts:

S_CTRL(pan=90) — commit clears loaded
first G_CTRL — live GET_CUR, sets loaded = 1
every read after that — cache hit, same value, until the move ends and the interrupt finally arrives

One live sample per write. And if userspace reads promptly after commanding the move, which is the natural thing to do, that one sample is taken before the actuator has appreciably moved. It's the least useful sample available. Polling is useless on any UVC PTZ camera, compliant or not.

The spec more or less concedes this. §4.2.2.1.15: a relative-control write "shall result in a Control Change interrupt for the Absolute Control at the end of the movement." The notification mechanism is event-shaped, and it's specified for the end of the move and nothing during it. That's fine for "auto-exposure changed mode." It's the wrong shape for a quantity that varies continuously for three seconds. V4L2_CTRL_FLAG_VOLATILE already exists for exactly this concept and uvcvideo just never applies it here.

So: patch.

The first patch was wrong in an interesting way

Four lines. Add a UVC_CTRL_FLAG_VOLATILE bit, set it on the pan/tilt entry, bypass the cache, surface the flag to userspace. Clean under checkpatch.pl --strict. I never sent it, and I'm glad.

One UVC control holds both axes — PANTILT_ABSOLUTE is 8 bytes, and PAN and TILT are 32-bit mappings at offsets 0 and 32. Because the mapping doesn't span the whole control, uvc_ctrl_set() does a read-modify-write on every single pan or tilt write. Make that read live and:

S_CTRL(pan=90) commits, gimbal starts moving
S_CTRL(tilt=20) a millisecond later re-reads live position. The gimbal hasn't physically moved yet, so it reads pan=0
commits SET_CUR(pan=0, tilt=20) — the pan command is cancelled

The write path only works today because the cache holds the commanded setpoint rather than reality. My own server issues pan and tilt as two parallel single-axis writes, so I'd have shipped a patch that broke the tool I'd hardware-verified, the moment it merged.

The commit message had a second problem: I'd quoted the UVC spec asserting the control "indicates the pan/tilt actuator's current position." Correct section number. The quote does not exist. I'd reconstructed it from memory and presented it as verbatim, and the real text uses setpoint language throughout. The citation that actually supports the argument was two subsections away the whole time.

The version I sent inverts the fix. Instead of adding a setpoint shadow so the write path can keep working — which means modifying the write path, which is exactly where the regression lived — it adds a separate read buffer. uvc_ctrl_set() comes out byte-for-byte identical to mainline. The regression isn't avoided, it's impossible by construction, and that's a much better thing to be able to tell a reviewer.

55 insertions, 4 deletions, two files. Hardware results on a self-built 7.2.0-rc4: the two-axis write passes with the hazard window genuinely exercised (pan still read 0 at the second write, and it still landed); live position steps 0→5→17→24→36→47→55→66→78→90 during a slew; 100 frames at 30.5 fps while polling position at 5 Hz with no frame loss; v4l2-compliance identical patched versus pristine.

It went to linux-media on July 25th, and Ricardo Ribalda picked it up six days later, opening with "I am not against the idea proposed by this patch" — then three questions and a counter-proposal. He suggested V4L2 control events instead, which fails three ways here: uvcvideo's only device-originated event is fed by the Control Change interrupt, the spec promises that interrupt only at the end of a move, and this camera never sends it at all. He also found a real hazard on the write side — once the AI has tracked the gimbal away from the last commanded pose, a single-axis write merges from the setpoint and yanks the other axis back. Real, but pre-existing: the patch leaves the write path byte-identical to mainline.

He came back the same evening, added Hans Verkuil to the thread, and said he was curious what HansV thought. So it's waiting on a second maintainer now, not on silence.

Two of his points I conceded outright. I'd overstated the accuracy requirement — nothing here correlates a position with a particular frame, and I'd answered a question as though it did. And he pointed out that VIDIOC_S_EXT_CTRLS sets both axes in a single commit, which sidesteps the write-path hazard entirely from userspace. I'd missed it completely. That one became a shipped fix in my own server the next day, which is the better outcome anyway: the patch is about the read side, and the write side had a userspace answer the whole time.

There's a nice accident buried in the retest, too. One run failed with the exact v1 signature — pan cancelled back to zero — and the cause wasn't my patch at all. The module reload had re-probed the camera while it was asleep, and asleep it doesn't answer GET_INFO, so the driver couldn't override the static table and pan/tilt kept AUTO_UPDATE. With that flag set, mainline clears loaded after every commit and does the live read-modify-write by itself. It's a stock-kernel bug on this camera. It's also not going in this patch — it's orthogonal, and bundling a second bug story into a commit message whose only real virtue is narrowness is how you lose a reviewer.

Where it landed

obsbot-mcp is on npm and does the thing I wanted: snapshot, find something in the frame, aim at that pixel, snapshot again to confirm. The aiming math reads the camera's own magnification out of its status block, so it works at any zoom without being told what the zoom is, and it refuses rather than guessing when it can't — AI tracking is fighting it for the gimbal, the zoom is still ramping, the camera had to be woken (waking moves the gimbal, so the frame you measured is stale).

35 tools on Windows and macOS, 34 on Linux, where speed-mode gimbal moves are hidden — a speed times duration burst can't be bounded without live position feedback, and until that patch lands, Linux doesn't have any.

A Pure-C# PDF Toolkit for .NET: Read, Create, Edit, Optimize, Render, Fill Forms — and No Native Dependencies

Michael Jordan — Wed, 24 Jun 2026 19:51:33 +0000

Most PDF libraries in .NET are wrappers. PDFium, MuPDF, Ghostscript — solid engines, but they ship native binaries you P/Invoke into. That buys you per-RID packages, Native AOT friction, the "works on my box, throws DllNotFoundException in the Alpine container" dance, and a deployment story that's never quite boring.

PdfLibrary takes the other road: the entire PDF engine — parsing, content streams, fonts, and every image codec (baseline and progressive JPEG, JPEG 2000, JBIG2, CCITT G3/G4 fax, LZW, Flate) — is pure managed C#. No vendored native PDF library, no native image decoders.

The first version of this post had an honest asterisk: rendering a page to pixels went through SkiaSharp, which carries a native component, and I wasn't going to pretend otherwise. 2.0 removed the asterisk. Rendering is now a small geometry-only interface the core hands flattened paths to — bring your own target, or use the in-box WPF one, which is managed WPF and ships no native code. The packages you install now have zero native dependencies. More on that below.

And rendering was always the flashy demo, not the point. So let me actually show you the toolkit.

What it does

One core package — Lxman.PdfLibrary — covers the whole document lifecycle, all managed:

Read & extract — parse any PDF 1.x or 2.0; pull text, with positions if you want them.
Create — build documents from scratch with a fluent builder.
Edit — add / remove / reorder / rotate pages, stamp, watermark, annotate, set metadata.
Optimize — losslessly shrink: compression, object/xref streams, font subsetting, optional image recompression.
Fill forms — read and fill AcroForm fields, regenerate appearances, flatten.

Pixels are the one thing that lives in a separate package, because most of the above never needs them.

Extract text

using PdfLibrary.Structure;

using var doc = PdfDocument.Load("input.pdf");
string text = doc.GetPage(0).ExtractText();

Edit a document

using PdfLibrary.Structure;

using var doc = PdfDocument.Load("input.pdf");
var edit = doc.Edit();

edit.Pages.RemoveAt(2);     // delete the 3rd page
edit.Pages.Rotate(0, 90);   // rotate the 1st page 90°
edit.Pages.Move(5, 0);      // move the 6th page to the front

edit.Save("edited.pdf");

Optimize / shrink

using PdfLibrary.Optimization;

using var doc = PdfDocument.Load("input.pdf");
using var output = File.Create("optimized.pdf");

PdfOptimizer.Optimize(doc, output);   // lossless by default

Fill a form

New and front-and-center in 2.0. Set field values, optionally flatten, save:

using PdfLibrary.Structure;
using PdfLibrary.Editing.Forms;

using var doc = PdfDocument.Load("form.pdf");
var edit = doc.Edit();

((PdfTextField)edit.Forms["applicant.name"]!).Value = "Ada Lovelace";
((PdfButtonField)edit.Forms["subscribe"]!).Check();

edit.Forms.Flatten();   // optional: bake the values into the page
edit.Save("filled.pdf");

Setting a value regenerates the field's appearance stream, so it renders correctly in any viewer afterward. (There's also a pure-WPF viewer in the repo that overlays native controls on the form fields so a person can fill them by hand and hit Save — but that's a post of its own.)

Render — and the "no native dependencies" story

Here's the 2.0 change worth understanding. The core flattens everything — including text, down to glyph outlines — and calls a small interface, IRenderTarget, with nothing but geometry: fill this path, stroke this path, draw this image, set this clip. About seventeen methods, none of which require any PDF knowledge to implement. The hard part — operators, fonts, color, clipping — stays in the core.

That makes rendering bring-your-own:

On Windows, install Lxman.PdfLibrary.Rendering.Wpf and render a page to a retained WPF DrawingGroup — vector, so it's crisp at any zoom — then host it or rasterize it. Managed WPF, no native code.

  using PdfLibrary.Rendering.Wpf;

  using var doc = PdfDocument.Load("input.pdf");
  DrawingGroup page = doc.GetPage(0).RenderToDrawing(scale: 2.0);
  // host `page` in an Image/DrawingImage, or render it into a
  // RenderTargetBitmap and PngBitmapEncoder it to a file.

Anywhere else, implement IRenderTarget against a canvas you already have — SkiaSharp, ImageSharp, System.Drawing, a printer, an SVG writer, a game engine. The repo ships an SVG target as a worked example; it's small.

So the honest breakdown, 2.0 edition:

Parse, extract, create, edit, optimize, fill forms → fully managed, ship no native code.
Render to a vector visual or a bitmap on Windows → Lxman.PdfLibrary.Rendering.Wpf, still no native code.
Render to a raster image cross-platform → you bring the canvas. WPF won't help you on Linux; that's the one line to be precise about. But "implement ~17 geometry methods" is a very different proposition from bundling and P/Invoking a native PDF engine.

No P/Invoke, no SetDllDirectory, no DllNotFoundException at 2am.

Threading

PdfLibrary is built for the one-document-per-request model — the standard ASP.NET Core pattern. Load a PdfDocument per request, work with it, dispose it. Under that model it's thread-safe, and the process-wide caches (glyph paths, font resolution, ICC profiles) are synchronized. The one thing you must not do is share a single PdfDocument across threads. (WPF rendering additionally wants an STA thread, as WPF always does.)

Install

dotnet add package Lxman.PdfLibrary
# rendering on Windows (optional):
dotnet add package Lxman.PdfLibrary.Rendering.Wpf

MongoDB-backed ASP.NET Core Identity, without the EF Core detour

Michael Jordan — Wed, 24 Jun 2026 19:42:41 +0000

If you're already running MongoDB and you reach for ASP.NET Core Identity, the
official story points you at Entity Framework Core. That's a fine answer if you
have a relational database. If you don't, you end up bolting a second data
access stack onto an app that has exactly one store. You don't need it.

AspNetCoreIdentity.MongoDriver is a store provider that talks to Mongo through
the official MongoDB.Driver directly — no EF Core, no SQL, no second
persistence model. It implements the Identity store interfaces, ships a
UserStore and RoleStore, and wires up UserManager/RoleManager the way
you already expect.

The 15-line version

builder.Services.AddIdentityMongoDbProvider<MongoUser<Guid>, MongoRole<Guid>, Guid>(identity =>
{
    identity.User.RequireUniqueEmail = true;
}, mongo =>
{
    mongo.ConnectionString = builder.Configuration.GetConnectionString("MongoDb")!;
});

A connection string like mongodb://localhost:27017/Identity creates an
Identity database and stores the collections there. That's the whole setup.
Now inject the managers wherever you need them:

public class AccountController(UserManager<MongoUser<Guid>> userManager) : Controller
{
    // ...
}

They're registered as scoped services — let the container manage their
lifetime. Don't call BuildServiceProvider() yourself, and don't cache the
managers in long-lived objects.

Your key type is yours

The MongoUser and MongoRole classes are generic, so the primary key isn't
forced to be a Guid. Want string keys? Use MongoUser<string>. If you use
string keys and don't assign an Id on create, the store generates an
ObjectId-style string for you.

If you do go with Guid, register the serializer once before the code above so
Mongo stores them in the standard representation:

BsonSerializer.RegisterSerializer(new GuidSerializer(GuidRepresentation.Standard));

Migrations that survive a rolling deploy

Here's the part that usually bites people who hand-roll a Mongo store. On the
first store operation — not during service registration — the library:

applies any pending schema migrations, guarded by a distributed lock so that if several app instances boot at once, the migrations apply exactly once; and
creates its indexes: a unique index on NormalizedUserName, an index on NormalizedEmail, a compound index on Logins.LoginProvider / Logins.ProviderKey, and a unique index on the role NormalizedName.

That distributed lock matters the moment you run more than one instance. Two
pods starting simultaneously won't race each other into a half-applied schema.

Because the NormalizedUserName index enforces real uniqueness, index creation
will fail if your existing data already contains duplicate user names — clean
those up before you upgrade. If you'd rather own these concerns yourself, set
mongo.DisableIndexCreation = true and/or mongo.DisableAutoMigrations = true.
And if you want the work done at startup instead of on first request, resolve
MongoIdentityInitializer and await EnsureInitializedAsync().

It won't silently clobber concurrent writes

Updates and deletes use optimistic concurrency through Identity's
ConcurrencyStamp. If the document changed since you loaded your copy, the
operation returns a ConcurrencyFailure instead of overwriting the other
write. Reload, reapply, retry — the normal Identity dance.

One honest limitation

options.Stores.ProtectPersonalData is not supported. The store doesn't
encrypt personal data at rest, and rather than letting you flip that switch and
quietly store unprotected data anyway, enabling it throws at runtime. If you
need encryption-at-rest for PII, handle it at a different layer.

Try it

dotnet add package AspNetCoreIdentity.MongoDriver

If you're on Mongo and Identity, this is the short path. Issues and PRs welcome.

DEV Community: Michael Jordan

It Started with Fonts: The Nearly Three-Month Road to Selling My Software

July: making it a company

August: a tax ID and a business checking account

There was another identity to sort out

September: adding a way to take payments

Approval wasn't the end of the list

October: finally available

What I'd tell another developer

Reverse-engineering the OBSBOT Tail 2: HTTP, USB, and a Linux kernel fix

The camera ships its own API client

A successful request can change nothing

Presets: the request schema was in the component

Getting a picture took a different protocol

The same USB GUID did not mean the same protocol

The Linux problem really was shared

What is usable now

Micro-compaction: amortizing context compression in agent loops

How it works

What the numbers say

The honest costs

Where it landed

I reverse-engineered a webcam so Claude could point it at things

Ghidra, headless

The bug that taught me not to trust my own opcode table

Then half of it turned out not to be vendor protocol at all

And it worked everywhere except Linux

The first patch was wrong in an interesting way

Where it landed

A Pure-C# PDF Toolkit for .NET: Read, Create, Edit, Optimize, Render, Fill Forms — and No Native Dependencies

What it does

Extract text

Edit a document

Optimize / shrink

Fill a form

Render — and the "no native dependencies" story

Threading

Install

Links

MongoDB-backed ASP.NET Core Identity, without the EF Core detour

The 15-line version

Your key type is yours

Migrations that survive a rolling deploy

It won't silently clobber concurrent writes

One honest limitation

Try it