channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=14
00:03:00 <klange> rtl8139 is a very old chipset, but it seems odd to disable support for a device like that
00:04:00 <klange> distro maintainers for qemu play around with frontend options a lot, and I'm still kinda mad about this gtk interface since it continues to have a bunch of issues
00:07:00 <kingoffrance> yeah, my understanding is rtl81[23]9 was like ne 2000 pretty universal for emulators to support, because almost any os had a driver
00:07:00 <kingoffrance> i of course dont know all the details/variants/etc.
00:08:00 <kazinsal> now everyone's got an e1000 driver
00:08:00 <klange> The default these days is e1000 and it's a much better choice
00:08:00 <klange> (-M q35, you get the PCIe "e1000e" variety)
00:09:00 <kazinsal> yeah, big bonus from the e1000e is that you get MSI and MSI-X
00:09:00 <kazinsal> and deeper queueing etc
00:11:00 <geist> if you want something old and similarly as complex as rtl8139 you can use pcnet32
00:11:00 <geist> from an earlier era, but pci native
00:11:00 <geist> and very documented
00:12:00 <geist> which qemu and a bunch of virtual machines emulate
00:12:00 <kazinsal> iirc vmware will do it if you set the nic type to "flexible"
00:13:00 <geist> but all this aside, qemu itself does understand rtl8139, at least the one i have here
00:13:00 <geist> it's listed in `-device help`
00:13:00 <klange> It used to be the default.
00:13:00 <klange> I wonder if a bunch if someone flubbed something when that switched to the e1000?
00:14:00 <klange> s/if a bunch//
00:14:00 <geist> yah and FWIW i'm using qemu 6.1, built from source
00:14:00 <geist> so the arch linux one could be patched or old or something, but there really isn't anything newer than 6.1 except tip-of-tree
00:15:00 <klange> looking at my git checkout from august, the code is still there
00:16:00 <klange> let's update this
00:17:00 <kaichiuchu> i think i might've made a mistake for what it's worth
00:17:00 <kaichiuchu> all I know is compiling from source was the only thing that worked
00:17:00 <kaichiuchu> heh
00:18:00 <geist> yeah dunno if the arch linux build maybe patched it out for some reason?
00:18:00 <klange> and they still haven't fixed double and triple click in the GTK interface being interrupted as a button release
00:18:00 <klange> idiots
00:18:00 <kingoffrance> eh, yeah it just sounded like a weird thing for them to disable, unless there was some known bug
00:25:00 <klange> Probably a good time to recover my rtl8139 and pcnet drivers...
00:26:00 <klange> They're the last bits of toaru32 I haven't ported over to misaka, just because they didn't feel worth the effort.
01:00:00 <klange> My ext2 driver is... doing some things wrong with locks that are making it difficult to fix up the ATA disk drivers... ugh, stupid me, you can't take a spin lock and then hold it through a potentially blocking operation, that's not how any of that works...
01:19:00 <junon> Custom build system is back to feature parity with the old cmake scripts. Mkrescue working now. Considerably less configuration necessary while being more flexible. I can also do per-file flags or custom toolchains and stuff without much fuss at all, unlike CMake.
01:20:00 <junon> Just need the Ninja maintainers to merge a PR and I can add CMake subproject support without much effort. Ninja currently doesn't handle subninja correctly at all IMO, and there's a PR to fix it. But it's hung up on Windows support weirdly enough.
06:10:00 <klange> today in distractions from a 2.0 release... tracking down why save games in doom don't work, it's calling rename(2) which I have yet to actually implement...
06:11:00 <klange> so okay we can do that the bad way and make it a move as if it were cross-filesystem, negating _why_ they do a rename, but let's just take a look at what we need to do support rename(2) nicely...
06:12:00 <klange> well it would be nice if I could know if two paths are in the same fs; this code is at least doing something in the easy case - rename file in same directory...
06:12:00 <klange> looking at what I shove in `struct stat` and just getting very mad at myself
06:17:00 <klange> This whole VFS needs a rewrite... which shouldn't affect userspace or the syscall interface, so it's not something I need to do now to not feel terrible about breaking compatibility...
06:17:00 <klange> It would be nice to actually support, like, actually relative file paths. And be able to implement all the *at() functions...
06:21:00 <zid> rename seems like it'd be fun to write tbh
06:23:00 <klange> It's "surprisingly powerful".
06:23:00 <zid> seems like you'd need to implement it per-fs though to get the real power of it
06:30:00 <klange> I think a big problem is that my VFS design caters more to the virtual device files I have, rather than actual filesystems...
06:30:00 <klange> I didn't really design much for things like know what "filesystem" a file is on.
06:33:00 <klange> There's room for that sort of thing in there, but it's not followed correctly
06:34:00 <klange> Like the main struct representing a file in the vfs has a ->device member and that _should_ be a pointer to something representative of the filesystem as a whole, but then I look at things like the tmpfs where nope that's the underlying structure of the file in memory
06:36:00 <klange> and _that_ was done because "the main struct representing a file in the vfs" isn't a shared thing like an inode cache entry, it's an instance specific to one call to open()... so it's more like a file descriptor...
06:38:00 <klange> a while back I was kicking myself over this same thing, as I was trying to figure out why an attempt to mark the size of a ramdisk as 0 after freeing it wasn't doing anything - of course because I set the size of a copy...
07:15:00 <graphitemaster> Why don't you design your filesystem based on market forces
07:15:00 <graphitemaster> klange, https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z
07:15:00 <bslsk05> 'Students who grew up with search engines might change STEM education forever' - 'Professors are struggling to teach Gen Z'
07:15:00 <graphitemaster> :D
07:29:00 * kingoffrance in honor of klange's time he referenced space balls "dont configure, just make!"
07:29:00 <kingoffrance> "Wait a minute! There's paths here! There's protocols (drive letters), there's trees, there's subdirectories in URLs, there's files at the end. Come on, we'll bless them all until we get vashnigyered [drunk] "
07:30:00 <kingoffrance> and the cycle begins again
07:33:00 <zid> kill em all and let the free market sort it out
07:35:00 <kingoffrance> the students or the professors?
08:32:00 <graphitemaster> The market has decided files are for boomers.
08:33:00 <zid> files should be associated with the app that created them, by the programmer, and nothing else
08:33:00 <zid> users should just get abstract representations, like thumbnail galleries or something
08:33:00 <sham1> The fact that smartphone manufacturers unironically agree with that is annoying
08:35:00 <kingoffrance> "the market has decided" thats the surest sign it will be reinvented under another name
08:36:00 <kingoffrance> not the market, i mean pretending something doesn't exist
08:36:00 <kingoffrance> it will be forced to be recreated
08:40:00 <graphitemaster> It's market forces, not market forced.
08:41:00 <kingoffrance> its just word games
08:41:00 <graphitemaster> The market maketh and taketh but your files were never safe
08:57:00 <GeDaMo> I feel like somebody in here was interested in synthesizers http://www.righto.com/2021/11/reverse-engineering-yamaha-dx7.html
08:57:00 <bslsk05> www.righto.com: Reverse-engineering the Yamaha DX7 synthesizer's sound chip from die photos
09:16:00 <kingoffrance> well i dont doubt conway's law -- ppl who grew up with x will be different than ppl from another env. but as a local dead tree paper article once said (paraphrase teacher) "we can create any kind of ppl you want" i dont mean that in a spooky controlled consciousness way, just that its a self-created problem of the education industry "market forces" if they think there is some "change"
09:17:00 <kingoffrance> if there was a change, they helped create it
09:17:00 <kingoffrance> and they can fix it if they wish
09:23:00 <kingoffrance> thats why i dont buy "students think differently" -- sure, because someone x years before you changed the curriculum/whatever
09:23:00 <kingoffrance> maybe teachers have little say, are bound by "market forces" but someone made that call
09:24:00 <geist> ooooh ken did a teardown of a synth chip. gnna be good
09:50:00 <geist> huh interesting: never knew about te trick of storing a sine wave in a table and then walking through the table with a different stride to generate different frequencies
09:51:00 <geist> seems pretty obvious once you notice it
09:51:00 <geist> (in the righto teardown article before talking about 80s FM synthesis)
09:57:00 <geist> GeDaMo: thanks for the link, that was really neat
09:58:00 <GeDaMo> Yeah :)
10:05:00 <geist> now i wonder a bit about the OPL3 and how it compares
10:05:00 <geist> it seems simpler, but probably a similar architecture
12:30:00 <GeDaMo> http://www.righto.com/2018/05/inside-76477-space-invaders-sound.html
12:30:00 <bslsk05> www.righto.com: Inside the 76477 Space Invaders sound effect chip: digital logic implemented with I2L
12:33:00 <zid> Not sure how this is different to pnp vs npn but I am also dumb
12:33:00 <zid> wait yes I do
17:27:00 <pounce> grr the genz fs article
17:27:00 <pounce> im gen z and i wrote an entire OS filesystem assignment for my students
17:27:00 <pounce> who are *also* gen z (well some of them) and they did great
17:28:00 <j`ey> which article is this?
17:28:00 <pounce> 23:15 <graphitemaster> klange, https://www.theverge.com/22684730/students-file-folder-directory-structure-education-gen-z
17:28:00 <bslsk05> 'Students who grew up with search engines might change STEM education forever' - 'Professors are struggling to teach Gen Z'
17:33:00 <j`ey> weird, never met anyone that didnt understand files/folders
17:34:00 <gog> yeah sounds like an extrapolation from a small sample
17:36:00 <jimbzy> bslsk05, I can believe that.
17:37:00 <jimbzy> I had to act as a translator between my CS professors and the other students...
17:37:00 <j`ey> jimbzy: bslsk05 is the bot :P
17:38:00 <clever> pounce: iOS isnt helping, the bulk of the UI just acts like folders dont exist, lol
17:40:00 <jimbzy> yeah I just realized that.
17:40:00 <pounce> yeah but everybody's going to have a different background on this, it's not like that's ever changed
17:40:00 <pounce> if you can't handle that it's not "gen z"'s fault
17:40:00 <jimbzy> I'm trying to ignore a meltdown in progress, so ignore me.
17:41:00 <pounce> :') good luck
17:45:00 <jimbzy> But seriously. Most of the CS students I have encountered have no interest in computers and/or science.
18:36:00 <sham1> Well could be that most CS students are after easy money
18:37:00 <j`ey> (which is also fine)
18:38:00 <sham1> It's fine
20:47:00 <geist> good afternoon folks
20:50:00 <jimbzy> What's happening, geist?
20:51:00 <geist> not much, had a nice windstorm here last night, but nothing fell down
20:51:00 <geist> so that's nice
20:54:00 <jimbzy> Yeah, that's always a good thing.
21:09:00 <gog> same here
21:09:00 <gog> found my neighbor's garbage bin in the street earlier :p
21:09:00 <gog> that's about it tho
21:21:00 <[itchyjunk]> I have a dumb question. can there be just one kernel? like say a cpu has a gpu as it's peripheral device. would each of these have their own "kernel" ?
21:21:00 <[itchyjunk]> or is it better to think of kernel as a top (bottom) level thing that nothing else superseeds?
21:21:00 <geist> hmm
21:22:00 <geist> not sure i completely understand what you mean by 'one kernel'
21:22:00 <geist> like one kernel as in a single code base, or one instance of a kernel running on both cpu and gpu at the same time?
21:22:00 <geist> for the latter. not really. gpus and cpus are different enough that trying to run the same code on both simultaneously isn't really realistic
21:22:00 <bauen1> intel (and arm) have already implemented hardware features so that the "kernel" in the traditional sense isn't the layer with the most privileges
21:22:00 <geist> but, gpus have their own firmware usually that the cpu talks to, so it works fine
21:23:00 <geist> same way that lots of peripherals have their own firmware with their own OS (think SSDs, or wifi chips, or SD cards, or whatnot)
21:23:00 <[itchyjunk]> not in the sense of being the same code base. rather the structure. like a car can have only one driver
21:23:00 <[itchyjunk]> even if there is another car hooked behind the first car, one driver controls the whole thing
21:23:00 <clever> even a usb3 chip can have its own firmware and cpu core
21:24:00 <geist> yah. so sure your model is fine. ignoring any special security processors or whatnot, usually the main cpu is 'in charge'
21:24:00 <[itchyjunk]> ah so each "cpu" would have it's own "kernel" and they just talk to each other then
21:24:00 <geist> or at least they think they are. there are levels of abstraction like virtualization or hidden security processors and whatnot that violate that rule
21:24:00 <geist> sure
21:25:00 <geist> a modern machine, and especially things like cell phones or tablets, have lots of little cpus running their own OS all talking to each other
21:25:00 <geist> the interface abstractions help keep the complexity of that to a minimum
21:26:00 <clever> there was a phone wifi exploit a few years ago called broadpwn
21:26:00 <[itchyjunk]> so there is no one piece of software in cell phone that is truly in charge
21:26:00 <clever> basically, the wifi chipset runs its own OS, that handles 90% of the idle wifi chatter, so the big arm cpu can stay in sleep mode
21:27:00 <clever> and there was a buffer overflow exploit in it, which can lead to remote code execution on the wifi chipset
21:27:00 <geist> [itchyjunk]: depends on your definition of in charge, so it gets a bit blurry
21:27:00 <[itchyjunk]> ah, useful to save power i assume
21:27:00 <geist> but conceptually the main cpu that the main os runs on is in charge yes
21:27:00 <clever> [itchyjunk]: until the firmware leads to a remote attacker having control of your wifi chip
21:27:00 <[itchyjunk]> right, i don't have good working definition for this stuff
21:27:00 <geist> though implementation wise you can make arguments as to which one has more authority to do stuff
21:28:00 <[itchyjunk]> clever, would you the arm part of the phone know that this other chip is executing random codes?
21:28:00 <geist> but as a product you want to give the illusion that the user is in control, so in general buttons that the user presses should go to a cpu that is running an OS that can respond to it and make global, visible changes
21:28:00 <clever> [itchyjunk]: probably not, enless your actively checking debug control registers
21:28:00 <geist> and usually that is what you'd probably consider 'in charge'
21:28:00 <clever> [itchyjunk]: depending on the variant of the wifi chip, it may be on a pci-e bus, and can then attack the host ram
21:29:00 <[itchyjunk]> hmmm
21:29:00 <geist> perhaps the button has its own io processor that already handled the button press? sure, but it forwards the results to the central 'main' OS
21:29:00 <geist> so in general the model would be there's a main cpu that runs a main OS and a cluster of various io processors each running their own, that talk to the main cpu
21:30:00 <geist> the details vary, but that's still a general model that most things follow
21:30:00 <[itchyjunk]> right, good enough
21:30:00 <clever> my work for the open rpi firmware is taking things in a bit of an odd direction, the same "OS" (little-kernel) is running on both the gpu and the arm core
21:31:00 <[itchyjunk]> different instance of same OS ?
21:31:00 <clever> [itchyjunk]: yeah, different builds (each for a different ISA), running on different cores, each with its own heap
21:31:00 <clever> and with different modules enabled
21:32:00 <[itchyjunk]> ah interesting
21:32:00 <clever> it gets really confusing, when your talking to both over the same uart
21:32:00 <clever> they are nearly identical, so you cant tell them apart, lol
21:32:00 <clever> ] whatareyou
21:32:00 <clever> i am VPU with cpuid 0x04000140
21:32:00 <clever> i had to add a custom command, that uses #ifdef's to figure out which ISA its on
21:32:00 <clever> and later added cpuid into it
21:34:00 <[itchyjunk]> i would think that a con of such thing is that redundant code is being run in each chip since once chip code might have been able to manage all that. what is the pro of this approach?
21:35:00 <clever> [itchyjunk]: the modules are configured so that each instance is managing different things
21:35:00 <clever> the GPU build manages initializing all of the hw (thats the only way to get the arm to even run) and driving the video output ports
21:35:00 <clever> the ARM build manages loading zImage + cmdline.txt + initrd from the SD card, and passing the arm core off to linux
21:35:00 <clever> but if you dont want linux involved, the ARM build could do other tasks directly
21:36:00 <clever> you could also ditch the ARM entirely, and have the GPU do the entire job by itself
21:37:00 <clever> but ive been writing the code in a portable manner, so i can easily move a task around
21:37:00 <noocsharp> does the gpu have an arm core? i imagine it must to load LK
21:38:00 <clever> noocsharp: the GPU on the rpi is a dual-core VPU (its own ISA)
21:38:00 <klange> < GeDaMo> I feel like somebody in here was interested in synthesizers http://www.righto.com/2021/11/reverse-engineering-yamaha-dx7.html ← I anonymously posted a fix for the demo being broken in Firefox and Ken applied it
21:38:00 <bslsk05> www.righto.com: Reverse-engineering the Yamaha DX7 synthesizer's sound chip from die photos
21:38:00 <clever> noocsharp: and the arm core where you typically run linux, is more of a peripheral hanging off the GPU
21:39:00 <noocsharp> yeah, i've always found it strange that you need proprietary firmware in order to even get a kernel running on the rpi
21:39:00 <clever> noocsharp: with the work ive been doing, you can boot a pi2 or pi3 headlessly with open firmware, or boot a pi2 to a full gui with a different open firmware
21:41:00 <noocsharp> sounds interesting, do you know of something similar for the pi1?
21:42:00 <clever> noocsharp: i can start linux on a pi1, but it crashes mid way thru the bootup
21:42:00 <clever> before it tries to mount the rootfs
21:42:00 <clever> all attempts to debug it just led to more confusion, the fault would move when i add print statements
21:42:00 <clever> but i now suspect i might have been overclocking it by 2x, or under-volting it
21:43:00 <clever> i dont change the voltages at all on any model
21:43:00 <clever> and the default voltage may not be high enough to run it at full tilt
21:47:00 <clever> noocsharp: next time i look into the pi1, i should both try lower freqs, and also investigate the voltage controls in more depth
21:47:00 <clever> parallel to all of that, is replacing the LK-arm payload with u-boot
21:47:00 <clever> or at least making it an option
21:48:00 <clever> i have 3 different payloads i can run on the arm, LK, uboot, or uefi
21:48:00 <clever> oh, and 4, the original rpi-open-firmware/arm_chainloader
21:48:00 <geist> how much time have you spent with the rpi-uefi stuff? is it a complete implementation?
21:49:00 <geist> curious, might be interesting to use it as a base for fuchsia porting
21:49:00 <geist> since uefi
21:49:00 <clever> geist: ive not worked on its code yet, or ran it, but i am in their discord server, and ask questions every now and then
21:49:00 <clever> it has both acpi and device-tree modes
21:51:00 <geist> yah i fiddled a bit the other day trying to figure out how to find the acpi tables on qemu-arm-virt. it's there, but it's hidden behind this fw_cfg interface
21:51:00 <geist> ie, not just mapped in memory like the device tree is
21:51:00 <geist> but presumably a UEFI implementation just pops it out of the fw_cfg interface
21:51:00 <geist> so it makes sense that that's where they put that
21:52:00 <clever> i think fw_cfg is meant to be a side-channel to pass data to the firmware (uefi), which should then re-expose it to the OS under more normal api's
21:52:00 <clever> but linux does have fw_cfg drivers, so it can peek
21:52:00 <geist> exactly
21:52:00 <clever> rpi-open-firmware needs similar things, because the arm core starts executing at pc=0, and there is no way to pass it arguments
21:53:00 <clever> so you need to edit the ram before you begin execution
21:53:00 <geist> all i really wanted to do was find the PCI ECAM, so i ended up resorting to just reading it out of the device tree, since i was already parsing that
22:00:00 <clever> geist: oh, but the rpi4 uefi, doesnt expose the pci-ecam, because its that wonky muxed one that acpi doesnt have a name for
22:01:00 <clever> that uefi will just claim the vl805 is a platform xhci controller
22:02:00 <geist> ah and it sets it up already configured and claming a fixed IRQ
22:02:00 <clever> yeah
22:02:00 <clever> the pci-e is pre-configured, and uefi just claims there is no pci-e
22:03:00 <clever> so you can just skip directly to MMIO'd the xhci registers
22:05:00 <geist> makes sense. not good for power management and you can't use MSIbut then if you just have a single IRQ it's probably not the end of the world
22:05:00 <geist> theres a bit of that shenanigans in the opposite direction on some of the thunderX arm socs
22:05:00 <geist> from reading the manual it loos like they have a bunch of 'fixed' peripherals like AHCI controllers and whatnot that also appear in their PCI ecam
22:06:00 <clever> weird
22:06:00 <geist> but... are fixed in location so yo ureally cant relocate them by reprogramming a PCI bar
22:06:00 <geist> so it's sort of a lie. here's a bus! but it's pretend
22:06:00 <geist> it's possible there's some obscure feature of PCIe that allows that. maybe there's a bit i dont know about that says 'this is a locked peripheral'
22:07:00 <clever> something else ive heard about, is that there is a max packet size for pci-e
22:07:00 <clever> and the bios is supposed to negotiate what the largest packet size is on a per-port basis, and set it as high as possible
22:07:00 <geist> they also of course have a real PCIe bus, but it's just some of the root peripherals are fixed in location. though possibly that's exactly what intel and amd does: peripherals on bus 0
22:07:00 <clever> and it was recently discovered, that the rpi4 linux drivers dont do that by default, because they assume the bios did it
22:08:00 <clever> so that was resulting in more overheads on the pci-e link
22:09:00 <geist> ah and are using like 1 byte at a time trnasfers or something
22:09:00 <geist> i can see that
22:09:00 <clever> 128 byte transfers i think, rather then 256 or 512 byte
22:09:00 <geist> i encourage you to give the pcie spec a read over. or at least as much as you can. it's fascinating at the link layer
22:09:00 <geist> like AXI but hella complicated
22:10:00 <clever> the forum thread went into detail of how many bytes of overhead are in each packet
22:10:00 <geist> and/or AXI looks trivial compared to
22:11:00 <clever> https://forums.raspberrypi.com/viewtopic.php?p=1879397#p1879397
22:11:00 <bslsk05> forums.raspberrypi.com: What happens if you add pci=pcie_bus_safe to cmdline.txt on a Pi 4? - Raspberry Pi Forums
22:11:00 <clever> yeah, it was defaulting to 128 byte packets, but the bcm2711+vl805 can support 256 byte packets
22:11:00 <clever> and the specs define a max of 4096 as the upper limit
22:12:00 <clever> and each packet will have 24 bytes of header, before the payload of the above size
22:12:00 <geist> the way pcie stripes across lanes and then reassembles at the end is super slick
22:12:00 <clever> so you can then add that all up, and divide by the pci-e link bandwidth
22:12:00 <clever> to get the actual useful data transfer bandwidth
22:13:00 <clever> i know of at least 4 protocols that can stripe over a variable number of lanes, SD, CSI, DSI, and PCI-e
22:14:00 <clever> SD does bit level striping, so you will send the 4 lower bits, then the 4 higher bits (not sure on order), over 4 wires, if in 4 lane mode
22:15:00 <clever> CSI does byte level striping, so each lane gets a whole byte
22:15:00 <clever> DSI/PCI-e, i aint got a clue
22:17:00 <clever> CSI also has a start/end symbol, which gets broadcast over all lanes
22:17:00 <geist> that's why i was suggesting it's a fun read to read the spec
22:17:00 <clever> so a csi transfer would look like [start,start], [byte0,byte1], [byte2,end], [end]
22:18:00 <clever> yeah, i need to find a pdf copy of the pci-e specs
22:25:00 <geist> yah i forget precisely how it's striped on pci-e. i think it's a byte at a time, but it also explicitly handles the fact that each serial link has its own clock and can arrive at different times
22:26:00 <geist> so there's some amount of packet level buffering that has to be done to reconstruct the packet with a fairly large amount of skew allowed
22:26:00 <clever> SD and CSI have one clock for the whole set
22:26:00 <clever> HDMI also has one clock, but some mechanims for tuning to the skew
22:26:00 <geist> right, this is one of those things that PCI-e explicitly deals with. running at hecka high frequencies, so each link is its own thing
22:27:00 <clever> for hdmi, there is a special set of 4 10bit symbols used in the blanking interval, with a very high edge densitity
22:27:00 <geist> and even at short distances like across the motherboard, at 5ghz or so you really start to see substantial skew
22:27:00 <clever> so the rx end can measure the exact skew between the re-created bitclock and each lane
22:27:00 <geist> yah, in other words HDMI is lame
22:27:00 <geist> or at least a product of the early 2000s
22:28:00 <clever> and hdmi has a special set of low edge densitity 10bit codes for the visible area, to reduce EMI
22:28:00 <clever> but the striping is super dumb, one lane per color :P
22:28:00 <geist> being that it's really just DVI in another package they had limited ability to deal with it
22:29:00 <geist> a bit dissapoint personally that displayport hasn't taken off in consumer TV space yet
22:29:00 <geist> dunno if it's a complexity thing, or licensing thing, or just HDMI is good enough thing
22:29:00 <clever> audio is done in the blanking interval