Tag: blog

Getting 1080p working via Intel i915 (Haswell 4600) -> HDMI -> VGA -> TV

For a project I recently started, I needed to build a semi-dedicated system. To make the cost a little more palatable, I planned to make it double as an HTPC (and maybe, in time, a Steam Box).

The TV I opted to use had its HDMI circuitry burn out late last year, so, as a workaround, I’ve been using an HDMI-to-VGA converter (HD2V04; does HDCP), which has been flawless with a PS3, but failed horribly when working with a device that actually wanted to trust EDID values, rather than just forcing its own fixed profiles, as a game console would.

Specifically, all EDID would enumerate was the VESA core-set and 1366×768, none of which looked good or even scaled properly on my display.

Adding definitions to xorg.conf repeatedly failed with “no mode of this name”, even when the mappings all appeared to check out. Using cvt and xrandr just resulted in unsupported video modes, making that seem like a dead-end, too. And i915.modeset=0 just made my DPI, which xorg.conf also failed to override, painfully wrong, to the point that there wasn’t enough detail to fonts to make out much of anything.

Ultimately, after lots of experimentation, I found a working configuration. The information below should work on most distributions, but have only been tested on Kubuntu 13.10.

First, you should try cvt 1920 1080 (using appropriate values), because, if it works, you’ll save yourself a bit of time. If not, then, like me, you can look for an appropriate modeline from the MythTV Modeline Database.

Once you have values, you’ll need to register them so xrandr will know what “1920×1080” means: xrandr --newmode "1920x1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

Then bind the new mode to the output you’re using: xrandr --addmode HDMI3 1920x1080 (you can find the name of your output, HDMI3 in my case, by running xrandr without arguments)

Finally, set the mode and refresh-rate to see if it works: xrandr --output HDMI3 --mode "1920x1080" --rate 60

If it doesn’t, you can set another mode, even if you can’t see your screen, by typing xrandr --output HDMI3 --mode "1024x768" --rate 60, which is almost certain to exist. (You can see all modes by typing xrandr without arguments)

Once you have a working value, you can make it permanent on-login by putting it in ~/.xprofile, which is executed as a series of instructions like any other script. I added a shebang and made the file executable for testing purposes, but this is probably not necessary.
xrandr –newmode "1920×1080" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
xrandr –addmode HDMI3 1920×1080
xrandr –output HDMI3 –mode "1920×1080" –rate 60

PING in pure Python

For work, I had need of running ping from a Python context in a memory-limited environment. Python was a given, parsing subprocess output is ugly, variable payload-sizes were required, and potentially many hosts would need to be pinged in parallel.

Seems like a great job for fping, but distributing external binaries is kinda tricky with this setup, so I did it in Python. (The other Python PING implementations, all of which seem to be derivatives of python-ping, either didn’t meet my basic needs, had more procedural namespace-bleed than I’d prefer to see, tried to do too much (requiring workaround logic to just do what’s actually needed), didn’t handle errors, or were GPL-licensed, which is unfortunately not something of which this process can make use)

The code, which is public domain, is available after the break.

Two video cards, three X sessions, five monitors: yes, it works

So I wanted a lot of screens for the new system I was building: lots of stuff to monitor, a reasonable amount of deskspace, and a desire to have at least one separate X session to handle fullscreen games without needing multiple profiles.

It wasn’t particularly difficult to set up, but documentation was sparse. To help anyone else who might be looking to do something similar, I’m providing my X config here; chances are, if you’re looking to do something similar, you’ll be able to figure out what needs to be tweaked.

Yay, long periods without updates

So, work being work, I haven’t had much time to do stuff. This post is mostly just a reminder that projects are being maintained.

There have been a few minor updates to prismscript: a few of the math.random functions previously resulted in recursion loops which have been fixed, regular expression support was added, and some types and namespaces were extended. All backwards-compatible changes.

pystrix has seen a few new features added and a couple of internal tweaks for compatibility with changes in Asterisk, though everything remains 1.10.x-compatible. I’ve also been working with Asterisk, as time permits (sadly, not often enough), to improve its conferencing module.

Lastly, I’ve started work on a new game against libgdx, intended to be playable (if not mostly complete) in time for the Ouya launch, but meant to be tablet-and-phone-friendly, too. That’s kinda back-burner, really only getting time while I’m in transit to and from the office, but progress is promising.

I’m still watching for feature-requests and bug notifications, so submit ’em if you’ve got ’em.

Feelin’… networky

As I get stuff set up to set about working on DHCPv6 support for staticDHCPd, I find that I now have five distinct subnets in a sub-1000sqft space. Yes, they all have a purpose (and will continue to exist long after 2.0 is out, ’cause I like my resources clearly defined by boundaries), yet I can’t help but feel that I’m doing something just a little unusual.

An idea for improving credit card security

It seems like there’s always some company or other letting its credit card database fall into the hands of a malicious party, whether it’s internal or through the Internet. It’s obvious that people don’t know what they’re doing when it comes to taking necessary precautions to protect their data, and that they’re really good at storing it in plain text, which makes it simple to index.

What if it were possible for the model to shift in a manner that both introduced multi-factor protection on data and lets the clueless keep doing business without needing to learn anything new or change their processes at all (particularly that plain-text thing, since it’s so efficient)?

What I’d suggest is really quite simple: don’t store credit card numbers anywhere. At all.

Now, of course, the first response I’d expect to hear, were I to stop there, is “but we can’t take a hash and reconstruct a value understood by the processors, and encryption still involves storing the number!”, and whoever were to say that would be entirely right. The next thing I’d expect to hear is “but if we do away with credit card numbers, users won’t know how to pay for things!”, and this, too, is right.

Credit cards wouldn’t have to go away or change form at all. Numbers would still be transmitted over the Internet, covered by whatever transport-layer security is deemed acceptable by the involved parties, but something magical would happen when they’re received: they’d be sent to the credit card company, just as they are now. Shocking revolutionary twist, isn’t it?

No, it’s not quite that simple, but it’s pretty close. The credit card number would be sent along with a credit-card-company-issued merchant-ID and a unique identifier would be sent back, forever marrying the customer’s payment method with the merchant (no cryptographic integrity needed — it can be a predictable, sequentially-issued number, so long as it draws from a universal, multi-merchant-accessible pool to let entropy do its thing to prevent systematic lookups). Upon receipt of this identifier, the credit card number would be discarded and the identifier could be stored as an attribute of the user’s account on the merchant’s end. When the user wants to make another purchase, the identifier gets sent to the credit card company again and the onus is solely on that party (which should have nigh-impenetrable security) to figure out which financial institution’s patron to charge for the transaction.

“Okay, so… uh… what if the identifier gets compromised?”, I imagine to be the looming question to be. The answer is elegant in its absolutism: nothing.

The identifier uniquely identifies a pair of entities: the customer and the merchant. If the credit card company receives an identifier from a party other than the merchant to which it is registered, the transaction is void (and easy to stop, through an immediate severance of the binding) and if the merchant attempts to act fraudulently, the customer has a very clear path of recourse. Consumer-protection failsafes notwithstanding, the only circumstances under which an attack would be profitable to a malicious party would be if the merchant provided goods or services they cared about, and for that vector to be exposed, the attacker would need to have inside knowledge of how data actually flows between components of the merchant’s architecture, which would require the compromise of many disparate systems, providing multi-factor protection through the omnipresent mashup of security-oriented design and brain-breaking “MAKE IT WORK NOW” kludges.

To summarise this idea, a single sufficiently large numeric identifier (probably 1024-bit to start, which allows potential for easy expansion and eternal backwards-compatibility) would identify a customer (credit card) and a merchant (registered business) in a manner intelligible only to the credit card provider, the party with the greatest investment in security. This identifier could be stored unencrypted in databases and be protected by processes and checks, rather than arms-race-oriented encryption and social trust.

The fact that this identifier is bound to exactly one relationship means that its external value is non-existent and that its potential for harm, should it slip, is limited to that one relationship, making it something that can be treated as an attribute of another pre-existing parallel relationship (the user’s account with the merchant — though one-offs are fine, too, if the merchant doesn’t need to request an identifier), which allows whatever security resources a merchant has to be focused on protecting user data in general, for the company’s benefit, rather than the patron’s. (Authentication like Amazon’s or that of reputable banks would be a beneficial, but unnecessary, complement)

Lastly, the way that the identifier is known to only two parties (the merchant and the credit card company) means that it can be quickly abandoned (from the merchant’s end) if it ever gets compromised, without having any more impact than requiring a new identifier to be issued in a subsequent transaction.

Just a thought, though. Feel free to cite this to help overturn any patents that may be issued around a similar idea — security shouldn’t be encumbered.
Seems Moneris has been doing something similar for a while. Oh, well. At least the idea’s been implemented in some capacity.

Symmetric encryption in pure Python (Blowfish)

For a project at work, it became obvious that I would need to implement some form of partial encryption between hosts in a self-configuring network. Nothing super-extreme, of course, since all traffic will exist within a closed environment; I just need enough protection to prevent casual observers from finding out enough about the protocol to inject malicious packets and provide some simple handshaking between the components of the system.

Blowfish came to mind as a good scheme for handling this (each host and operator can be considered sufficiently secure, so sharing an application-specific pass-phrase via config-file is an acceptable solution), and a small amount of Googling turned up http://ivoras.sharanet.org/projects/blowfish.html (based on http://felipetonello.com/scripts/python/blowfish.txt, though I doubt that’s the original site), which I ended up using as the basis for my implementation. Actually, ‘basis’ isn’t the right word, since I didn’t change any logic at all. Rather, I just replaced the more antiquated data-types and access methods with more modern equivalents, restructured the layout, and sought to bring things more in line with PEP 8. The result being a slightly faster, leaner implementation that’s a bit more readable.

My code, with an identical interface to Ivan Voras’s version, dual-licensed under the GPLv1 and Artistic Licenses, like the original, is reproduced below:

A month of silence

Between a general lack of free time and a number of short-term tasks, I haven’t had much of an opportunity to do anything with the projects hosted here (or even to prepare for PyWeek). Work will resume next month, once I’ve got a real schedule around which to plan my time.

What time I’ve had has been contributed to the development of Quickshot for the Ubuntu Manual project, so it could make the deadline imposed by the launch of 10.04. Progress is steady, so look forward to the first release of the manual in its many languages, if you’ve been on the fence about switching.

Pretty At3 CDs

My At3 discs finally arrived (though FedEx’s duties overhead for Canada is pretty brutal). I’ll start adding content to the Hymmnoserver based on what I glean from the inserts and aquagon‘s updates to the Conlang article as soon as I get a break from work.

Tracklist translations: OST (disc 1, disc 2), Hymmnos concert side (blue, red)

Update: Unfortunately, that “break from work” probably won’t be happening this weekend. More unpaid overtime for me.