<d1b2>
<timonsku> ah no the restrictions were other mechanical feature, components on the board wouldn't be an issue 🙂
<electronic_eel>
ok, was just an idea if that would help with the case
<d1b2>
<timonsku> again I already fixed that mostly and increased size, I will try hat prob. this week with a lightpipe there too
<d1b2>
<timonsku> thanks though
<electronic_eel>
@timonsku does this highlight properly?
<d1b2>
<OmniTechnoMancer> No
<d1b2>
<OmniTechnoMancer> Try with #8387 on the end
<d1b2>
<OmniTechnoMancer> But I suspect the sending client needs to translate it into a user reference or something and unsure what the bridge not does
FFY00 has quit [Ping timeout: 260 seconds]
<DX-MON>
I'll ping myself then: DX-MON#9200
<DX-MON>
hmm.. maybe then it's @DX-MON#9200
<d1b2>
<DX-MON> yeah, nope.. that doesn't work Omni
<DX-MON>
I'm fairly sure if I just say my Discord user name accurately as in DX-MON it should highlight properly - not the lack of punctuation around the mention
<d1b2>
<DX-MON> ok, that didn't work either so I'll stop now so I don't spam the channel
<d1b2>
<geo> you could try using discord id?
<d1b2>
<geo> like <@397464999494418444>
<DX-MON>
uh, where would I find that in the interface?
<DX-MON>
even something like #9200 doesn't seem to work
<d1b2>
<geo> uhh you need to enable developer mode in the settings, then you can right click a message from the person you want to @ and click copy id
<DX-MON>
ah, I've got to think this works without having to go full medievil on it.. I mean, does @DX-MON work? I bet not seeing no combo of attempted mention has yet pinged me
<d1b2>
<DX-MON> anyway.. it's possibly a bot problem where the bot needs a restart to get the newest Discord update or something
<sorear>
does it work for people without nonword characters in their nicks?
FFY00 has joined #glasgow
<DX-MON>
good question.. I don't want to attempt any further tonight for sake of it being seriously off topic and now filling Discord scrollback though
<d1b2>
<esden> Humm it might also be an issue with the bridge... I should update it probably. I also don't have the patch @Qyriad wrote merged...
<d1b2>
<esden> (I am slightly reluctant to touch it as it is written all in node and it scares me)
<d1b2>
<Qyriad> I don't think my patch has anything to do with this …I think.
<d1b2>
<esden> @Qyriad I would agree... it would just be a side effect of me updating the bridge...
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
d1b2 has quit [Remote host closed the connection]
d1b2 has joined #glasgow
<esden>
ok just FYI the bridge is updated now and on it's "best behavior" ... :)
<esden>
so @esden will highlight me on the discord side
<esden>
as well as
<esden>
esden: will do the same
<esden>
just inline names are not automatically converted to highlights, an @ is necessary.
<esden>
</offtopic>
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 272 seconds]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 256 seconds]
PyroPeter_ is now known as PyroPeter
Stormwind_mobile has quit [Read error: Connection reset by peer]
<whitequark>
even though it hangs like every other time i run it and has bizarre TUI bugs i still feel ten times more productive with it than with wireshark
Chips4Makers has quit [Ping timeout: 272 seconds]
Chips4Makers has joined #glasgow
Sellerie has quit [Quit: Ping timeout (120 seconds)]
Sellerie has joined #glasgow
bvernoux has joined #glasgow
<ktemkin>
whitequark: thanks! it's pretty much @Qyriad's project these days
<ktemkin>
so she's the one deserving of any thanks
<d1b2>
<Qyriad> I haven't worked on the TUI in ages whoops
<ktemkin>
I wrote a quick/rushed prototype in a hotel before a conference and then handed it off to her
<whitequark>
Qyriad: viewsb is Good thank you :)
<d1b2>
<Qyriad> Thanks >.>
<whitequark>
i *think* there's something screwy with FFY00's patch that adds exception pipes
<whitequark>
it hangs a lot on my machine, and also swallows exceptions. i'll probably get to debugging it, eventually
Foxyloxy has quit [Quit: Leaving]
<whitequark>
Qyriad: is it me or is urwid kinda... impenetrable?
<whitequark>
i just spent 30 minutes trying to figure out how to defocus a widget and i'm not any closer
<d1b2>
<Qyriad> re: FFY00's patch, if it's causing problems I can revert it. It provides some niceties but end-user-usability is more valuable. As for urwid, that's ktemkin's domain. I haven't looked into it any more than trying to add something to the main loop, but based on that I find what you're saying to be very believable
<ktemkin>
whitequark: it is impenetrable
<whitequark>
Qyriad: I wouldn't personally revert it yet; I'd have to read the code closely to see if it's salvageable or not first
<whitequark>
the amount of races is worrying but maybe it's something easy to fix
<whitequark>
ktemkin: also is it me or is it kind of... slow
<ktemkin>
urwid?
<whitequark>
yea
<ktemkin>
yes
<whitequark>
does it have any redeeming qualities
<ktemkin>
it let me get as far as I did in four days
<whitequark>
fair
<whitequark>
Qyriad: the one particularly annoying thing about (I believe) that patch is that it breaks printf debugging for reasons I don't entirely understand
<whitequark>
actually, speaking of race conditions
<whitequark>
can you explain what's up with the multiprocessing stuff?
<ktemkin>
as in 'why the three procesess are there'?
<whitequark>
p much
<whitequark>
i'm not sure what kind of throughput is viewsb designed for
<d1b2>
<Qyriad> I think the answer is "it wasn't"
<whitequark>
but given that it's in python and uses a weird and slow UI toolkit, i somehow expec... ok
<ktemkin>
beacuse backends like OpenVizsla (and theoretically Sigrok) pretty much need to control the process space
<whitequark>
hmm
<whitequark>
how so?
<ktemkin>
OpenVizsla has some ancient code that scanlime wrote that IIRC spins up threads itself
<ktemkin>
libov
<whitequark>
that doesn't sound *inherently* incompatible with python
<ktemkin>
that I didn't want to rewrite or touch
<d1b2>
<Qyriad> Also I think we wanted to bypass the GIL
<whitequark>
hrm
<whitequark>
i kinda see
<ktemkin>
Qyriad: (native code can bypass the GIL itself, it's just touchy)
<whitequark>
ctypes can bypass GIL too
<ktemkin>
whitequark: and libov's performance tanks if it doesn't wind up independently scheduled
<whitequark>
right, i thought i was missing something
* whitequark
sighs
<whitequark>
so you know how this all started?
<whitequark>
i realized that i misunderstood USB control transfers for like. the entire time i worked with USB.
<whitequark>
take a look at glasgow's main.c. it has a comment that explains my mistake in great detail
<whitequark>
i should not have added ST_ERROR but rather stopped clearing HSNAK immediately after SETUP stage, effectively making STATUS stage useless
<whitequark>
at the time i thought that this was kinda stupid, but i didn't realize that the stupid part was me. anyway, i sat down to fix this, which incidentally involves breaking all libfx2 downstream code in existence
* ktemkin
doesn't see the comment -- is it in `master`?
<whitequark>
the cypress compatible EEPROM bootloader works great, i finally fixed a bug where failed EEPROM writes wouldn't raise an exception by using the STATUS stage properly
<whitequark>
i have no idea how i managed to read the FX2 USB explainer very closely probably dozens of times and still not actually understand the basic structure of the transaction, but oh well
<whitequark>
so i fixed the cypress/fx2tool bootloader, right? then i went to update all of my example code, which would double as making sure i actually do understand it properly now
<whitequark>
and the dfu bootloader doesn't work, and i have no idea why, so i tried looking at wireshark
<whitequark>
which is miserable because wireshark is the second worst tool to look at usbmon after hexdump, narrowly
<whitequark>
so i tried looking at viewsb, which is *way* better in the sense that i'm finally getting *somewhere*, but on the other hand it means i am now fixing viewsb UI papercuts
<ktemkin>
I literally started ViewSB because wireshark sucked so badly, and I wanted a "free" analyzer to use in trainings
<whitequark>
hahahahaha
<Qyriad>
whitequark: yeah I am, unfortunately, very familiar with that problem. it's especially bad when I try to use ViewSB to debug ViewSB
<whitequark>
so i would be basically fine with rewriting half of viewsb but
<whitequark>
now it turns out that openvizsla needs to be turned into something that works, too
<whitequark>
you know *why* i started all this?
<whitequark>
so a few days ago timonsku asked me to add a mode that would light up all leds on glasgow
<whitequark>
which are scattered all across the firmware cuz 8051 and ISRs and all that
<whitequark>
so i started refactoring the LEDs
<whitequark>
and the ST_ERROR status bit lights up a LED but it really oughtn't because it ought not exist in first place
<whitequark>
which i realized by comlete accident while scrolling the FX2 TRM absentmindedly and landing on a sentence that basically explained me how i made libfx2 totally wrong
<whitequark>
i am now looking at ov_ftdi. this is *counts* 7 levels of yak shaving deep
<ktemkin>
I was just about to comment on your yak stack
<whitequark>
i *just* managed to get my 10 used virtual desktops down to uh, 5
<Qyriad>
still better than my tab count =P
<FFY00>
whitequark, can you open a bug to discuss the issue?
<whitequark>
i think the most terrifying part is that i know i can probably fix *gestures* all of that. eventually
<ktemkin>
so, what it really comes down to is: if I get around to writing an SDRAM driver for OV hardware in nMigen, libov can just die
<ktemkin>
since OV can just run LUNA gatware
<whitequark>
oooooo
<whitequark>
you know, i always wanted to write an SDRAM driver
<whitequark>
i don't even need SDRAM, i just think the state diagram looks like the tree of sephiroth, so it must be fun to get to actually work
<whitequark>
i even bought some random SDRAM (about four years ago at this point)
<ktemkin>
I still need to actually implement the LUNA analyzer backend properly (e.g. come up with a binary format spec for captures and implement it), which in turn is waiting on me getting all this USB3 stuff done and then do some educational stuff I promised
<whitequark>
you live like this huh
<whitequark>
and so do i
<ktemkin>
it's yaks all the way down
<Qyriad>
at which point the way to run the openvizsla backend would be `LUNA_PLATFORM=luna.gateware.platform.openvizsla:OpenVizslaPlatform ./viewsb.sh luna`, lol
<Qyriad>
also I still need to finish migrating LUNA over to python-libusb1
<whitequark>
hell yeah
<whitequark>
from what? pyusb?
<Qyriad>
yeah
<whitequark>
is it bad?
<ktemkin>
pyusb?
<Qyriad>
well ktemkin wanted to switch to using asynchronous transfers
<ktemkin>
more pythonic, doesn't support async
<whitequark>
i see
<whitequark>
(cc FFY00, we just discussed that on birdsite)
<Qyriad>
I ran into some weirdness that shouldn't even be _possible_ when capturing analysis data with async transfers
<ktemkin>
oh yeah
<ktemkin>
you asked me to help you debug that like six months ago
<ktemkin>
and I never did
<whitequark>
hm, by "async" you mean "different poller thread" right?
<whitequark>
because on windows you cannot put USB descriptors into the event loop
<FFY00>
it was an overview from my part, sorry, I had forgotten about it
<whitequark>
this is why glasgow does "async" usb transfers using threads on all platforms. it's just less headache to have it be uniformly bad rather than good on linux and not good on windows
<whitequark>
NameError: name 'QApplication' is not defined
<whitequark>
yep
<Qyriad>
do you have PySide2?
<Qyriad>
installed, I mean
<whitequark>
i have... but it's the one from debian
<Qyriad>
It's _supposed_ to mark the Qt UI as—ah.
<whitequark>
so it's probably fucked up in some subtle but fundamental way
<ktemkin>
Qyriad: "whitequark: if you have the time/energy/willingness" <-- if you bring something up in front of whitequark as a possible technical issue or solution, you've already gone a lot of the way towards reallocating her energy~
<Qyriad>
try installing it with pip, I guess?
<Qyriad>
ktemkin: …good point.
<whitequark>
:3
<Qyriad>
to be fair, I'm trying to solve _her_ problem instead of getting her to solve _my_ problem...despite them technically being both of our problems =P
<whitequark>
i mean, i'm lucky in that this sort of problem makes me feel better, not worse
<whitequark>
not universally, but usually
<whitequark>
the only time when it made me intensely depressed was when i tried to run a .net 4.5 game launcher, which was shipped by a publisher specifically to be launched under wine, under wine
<Qyriad>
under wine twice? what?
<whitequark>
no like
<whitequark>
it was designed to be run under wine, right?
<Qyriad>
yeah
<whitequark>
and i am trying to run it under wine.
<ktemkin>
Qyriad: she tried using the thing that's meant to work in wine, in wine
<Qyriad>
I...take it that it didn't work as planned
<whitequark>
the thing is that it has been going on for months, and at one point i have got into a huge fight with my roommate (yes, because of .net under wine) and we haven't talked for a week
<whitequark>
i have since managed to break the copy protection on the game it was supposed to be launching, automated breaking of said copy protection, got 3d audio to work, and then got in-game radio with a teamspeak plugin to work reliably
<whitequark>
that fucking launcher though?
<whitequark>
i'm pretty sure it actually reduced me to tears once or twice
<Qyriad>
jesus
<Qyriad>
that's awful
<whitequark>
i am playing the game under wine, obviously. with a thunderbolt egpu. through a vulkan translation layer. it works *perfectly*.
<whitequark>
but the launcher? hell No
<Qyriad>
I...don't suppose you can run the game without the launcher?
<ktemkin>
I mean
<whitequark>
well that's what i did. i broke the copy protection on the steam release.
<whitequark>
in like... 20 minutes.
<Qyriad>
ahh gotcha
<whitequark>
i probably didn't *have* to do that, but it was easier than figuring out how to get steam's incomprehensible idea of a wine distribution to do anything useful
<whitequark>
until i tried using proton i didn't realize wine was phenomenally reliable and also user friendly (in comparison)
<whitequark>
like... how
<whitequark>
the whole situation is mindboggling, i feel like i'm being pranked
<Qyriad>
yeah you've mentioned proton being horribly borked before and even just that boggles my mind since its literal only purpose is to be a less borked wine
<whitequark>
the only time i experienced proton working better was when i installed a *community fork of proton*
<Qyriad>
now *that* I believe readily
<whitequark>
i think it's better in that like, they fixed cutscenes that use weird multimedia APIs
<whitequark>
and somehow broke everything else
<ktemkin>
this is literally why I only really console game
<Qyriad>
meanwhile I was going to say this is why we have a windows PC dedicated for playing games
<Qyriad>
and pretty much only to playing games
<whitequark>
ktemkin: ok so like, roommate got me into arma 3 and when she gave me the (pirated, obviously) binary i ran it under wine on my egpu mostly as like, a joke
<whitequark>
and it just worked instantly
<whitequark>
and then some sort of inner demon got me to pay for the god damn thing
<whitequark>
and the suffering has not stopped since
<Qyriad>
sidenote: you got an egpu working in Linux, and under wine no less?? that sounds like black magic already
<whitequark>
nvidia egpu, too
<Qyriad>
wat
<ktemkin>
Qyriad: I use an eGPU with my Linux laptop work desktop; that's how I have all the monitors there
<ktemkin>
I didn't have to do much of anything
<whitequark>
it's super reliable, and has performance comparable with what i can get on windows
<Qyriad>
ktemkin: is that a full eGPU? I thought I asked you if it was and you went "no it's a thunderbolt 3 dock it's similar but also very different"
<ktemkin>
it's a PCIe-to-PCIe bridge with a GPU underit
<ktemkin>
*under it
<ktemkin>
it also has a bunch of other PCIe devices on the bridge
<whitequark>
i basically never had any problems related to it being a egpu, except for the fact that Alpine Ridge has really really really bad EMI issues and if i forget my phone oh the Thunderbolt cable, the moment it decides to talk to the BTS, the TBT link drops and my X server crashes
<ktemkin>
meanwhile, I use an eGPU at home on macOS and it's just transparent as hell
<whitequark>
but that's like, an intel problem, not an nvidia problem
<ktemkin>
so it pretty much seems like Windows is the only one with eGPU issues
<Qyriad>
well X crashing because of GPU stuff is not surprising in the slightest
<whitequark>
ktemkin: i actually found that it was easier to get eGPU to work on windows than on linux
<whitequark>
i install LTSB, i boot with the eGPU, it pulls out the drivers from winupdate, reboots five times or so, i get a widget in the tray i can use to zoop applications onto the nvidia
<Qyriad>
"reboots five times or so" <--- lol
<Qyriad>
nice that it gives you a fancy tray widget to zoop things too though
<Qyriad>
things to*
<whitequark>
yes, and i can't stress it enough, it did all that autonomously through winupdate
<whitequark>
i didn't even have to open nvidia's website
<ktemkin>
I didn't; Windows decides to get confused about what PCIe is when I plug in mine
<whitequark>
like, it was straightforward on linux, but on linux i had to read english text. windows, literal plug and play
<whitequark>
however
<whitequark>
normal people, who do not run LTSB, do not get this experience.
<Qyriad>
it would be hilarious if only nvidia GPUs Just Work on Windows
<whitequark>
my roommate installed Win10Pro (i think?) and then she spent like a day trying to get *any* kind of nvidia drivers to install *at all*
<whitequark>
because microsoft has shipped some sort of improved driver architecture, and now they don't work
<whitequark>
like, it downloads the same thing over winupdate that it downloaded on my LTSB, and then it refuses to install it, because it's not stateless enough
<whitequark>
and there's absolutely nothing you can do because the entire process is opaque with no opportunity to affect it
<ktemkin>
I plugged in mine, it got assigned a BDF, Windows said "okay, I know how to do this", it restarted, and then the BIOS assigned it a different BDF, and Windows said "I have the eGPU drivers installed already, and it's not there" until I edited the registry
<whitequark>
she fixed this by wiping the disk and installing LTSB.
<whitequark>
so in the end it is actually easier on linux lo
<whitequark>
*lol
<whitequark>
actually, in my current laptop i have a quadro t2000 (don't ask) and it has working power management, up to and including RTD3
<whitequark>
i have eGPU enabled in Xorg.conf and i still get 5-6 W of baseline power consumption because they *Finally* got it to work
<whitequark>
only took, uh, ten years?
<Qyriad>
"and there's absolutely nothing you can do because the entire process is opaque with no opportunity to affect it" <-- so, the Windows Experience
<whitequark>
(this is the second quadro gpu i bought intending to do nothing but play games on it. there were uh... reasons.)
Foxyloxy has joined #glasgow
<Qyriad>
there usually are
<whitequark>
i was briefly excited to try and bring up a vGPU until i discovered that i need (a) an NDA, (b) a specially fused GPU, (c) a contract with IBM, and (d) fucking vSphere
<ktemkin>
man, not breaking NDAs sucks
<Qyriad>
(vGPU?)
<whitequark>
at which point i brought up an Intel vGPU instead, which works (albeit with a disappointingly small framebuffer), but macOS in KVM doesn't like booting on it because it doesn't have some kernel component or something
<whitequark>
GPU virtualization
<whitequark>
think SR-IOV but for GPUs
<ktemkin>
people say things like "I want to understand how this NVIDIA-related virtualization technology works" and I'm like "I wonder how much trouble I'd get in if I just forwarded some PDFs along"
<Qyriad>
I don't know what SR-IOV is but I get the idea
<ktemkin>
IO virtuazliation technology that lets you create multiple "virtual functions", essentially splitting an I/O device into multiple "virtual" ones
<whitequark>
one of the modes lets me (well, ok, not me. someone with an IBM contract) slice the quadro device into several functions and pass them through to VMs
<whitequark>
yup
<hl>
...why IBM?
<whitequark>
hl: ask nvidia
<hl>
oh right
<Qyriad>
ktemkin: ~~just threaten them with another vulnerability I'm sure it'll go fine~~
<hl>
IBM partnered with NVIDIA to bring their stuff to their POWER servers
<hl>
which is why NVIDIA provides a ppc64le driver, incidentially (with some horrific EULA as usual, plus it apparently supports only compute and not graphics)
<whitequark>
oh did i mention (e) custom build of RedHat that has NVIDIA's custom build of drivers
<ktemkin>
Qyriad: last time I dropped a major vulnerability on them, it turned out awkward: later, I wound up at a house party with the head of security for NVIDIA ~
<whitequark>
their entire stack seems to be carefully designed to be as repulsive to even read about as possible
<whitequark>
software aposematism?
<Qyriad>
tired: putting heavy legal restrictions on your software
<Qyriad>
wired: making everything about it and related to it so godsdamn painful to read that just no one bothers
<whitequark>
*far* more effective
<ktemkin>
anyways, whitequark: if you wind up doing major work on ViewSB at least let me figure out paying you for it
<whitequark>
as a silicon vendor, your capacity to produce a seemingly infinite amount of layers of truly awful architecture is boundless, and your adversaries' capacity for looking at it is very much not
<Qyriad>
(also I think if you install PySide2 with pip it should work fine)
<FFY00>
eh
<FFY00>
it comes with 400MB of bundled Qt libraries and expects you to have the dependencies
<FFY00>
so, things could go wrong
<FFY00>
;)
<ktemkin>
things going wrong? on Debian?
<ktemkin>
surely you jest
<FFY00>
the nasty issues come when the ABI of the libraries they expect are different
<Qyriad>
FFY00: obviously, but it should still be better than using the pyside2 debian package
<Qyriad>
Which apparently doesn't work
<FFY00>
probably, I haven't used debian in a while
<Qyriad>
Apparently I should spin up a debian container or something and make sure ViewSB actually works on it >.>
<whitequark>
there's not a pyside2 debian package
<Qyriad>
Oh
<whitequark>
there's like thirty of them and i'm missing some
<Qyriad>
Ahh
<whitequark>
where does QUiLoader live.
<Qyriad>
Even worse
<Qyriad>
Uhh
<whitequark>
qtuitools. but i *did* install that.
* whitequark
stares menacingly at aptitude
<FFY00>
you should probably be able to use PyQt5
<FFY00>
which I believe is packages
<Qyriad>
She'd have to change the imports but theoretically that would work yes
<FFY00>
it is essentially the same API as pyside2
<Qyriad>
The reason we don't use PyQt is licensing, incidentally
<whitequark>
how come i have PySide2.QtUiTools but i don't have QUiLoader inside of i
<whitequark>
ohhhh, it's because it wants QtXml. but there's no dependency in the debian package for some reason.
<Qyriad>
is there no "install every PySide2 package" option
<whitequark>
yes but i'm sure that if i do that, i'll hit the issue where debian builds *everything* with *every* possible dependency and it inevitably conflicts with something else
<whitequark>
and like. for the last six months apt insists that i have to upgrade libc but that under no circumstances it will let me upgrade libc
<whitequark>
sure, i could make that worse voluntarily,
<whitequark>
anyway it runs now
<Qyriad>
yay
<whitequark>
hm. i think the TUI felt a lot more usable
<Qyriad>
"and like. for the last six months apt insists that i have to upgrade libc but that under no circumstances it will let me upgrade libc" yeah this sounds perfectly in brand
<Qyriad>
The TUI might still be more usable
* whitequark
sighs
<Qyriad>
There's some usability improvements like icons and colors coming to the Qt UI that I've been meaning to do for forever
<whitequark>
time to figure out how urwid works, i think
<FFY00>
I was doing that
<FFY00>
to fix the handle_exceptions issue
<whitequark>
hey, look at the positive side! once i'm done, i will dislike it in ways that are as of yet inconceivable
<whitequark>
Qyriad: the colors are a big one, but i think the GUI requires some careful work on the way it divides the screen into display areas for it to get truly good
<whitequark>
the TUI is very good at this right now
<ktemkin>
I think those QT areas are dockable
<whitequark>
oh sure
<ktemkin>
so you can splork them all around
<FFY00>
Qyriad, have you tried kivy?
<FFY00>
I was thinking of writing a gui with it
<whitequark>
i would probably start by making the hexdump window have the minimum width of the hexdump in it
<whitequark>
and then squeezing the table a bit
<Qyriad>
whitequark: you're absolutely right; unfortunately I am trash at UI design so I've been waiting on ktemkin
<FFY00>
you can see why I am not a very big fan of the Qt gui :P
<Qyriad>
FFY00: that's why I was asking about your issues with it on github heh
<whitequark>
yeah, it's actually surprisingly hard to make a usable GUI... even if it's just three panes
<Qyriad>
Alas, I don't have a HiDPI display to test with
<FFY00>
I don't have those little tree things in the packets :(
<whitequark>
are they invisible maybe? white?
<whitequark>
wait
<Qyriad>
If you're using usbmon and it's just interrupt I don't think you'll see any subordinates
<whitequark>
those are just interrupt transfers
<whitequark>
yes
<whitequark>
are the sub-packets basically just different parts of a single IRP?
<whitequark>
sorry, URB?
<ktemkin>
on usbmon, yes, I believe so
<whitequark>
fun
<ktemkin>
the backend splits the URB reports into subpackets similar to what a hardware analyzer would see
<ktemkin>
for control requests
<ktemkin>
otherwise they show up as completely unintuitive garbage
<ktemkin>
(I wrote the usbmon backend on a plane specifically so I wouldn't have to have a hardware analyzer plugged in to test things on the tray table)
* whitequark
stares at wireshark
<ktemkin>
(and so I could easily replay USB data)
<whitequark>
you know, i fixed a lot of problems looking at wireshark usbmon, and now i'm realizing i didn't have to
<whitequark>
it's bittersweet
Foxyloxy has quit [Remote host closed the connection]
<whitequark>
wasn't there an even more cursed usbmon? didn't the first iteration use like. ascii over debugfs capped to 64 chars?
<ktemkin>
it's actually the same device
<ktemkin>
just squished over to dev
<whitequark>
thanks i hate it
<ktemkin>
IIRC if you use read() you get ascii, if you ioctl() you get binary
<whitequark>
i will never look at usbmon source code
* whitequark
opens lxr
<ktemkin>
oh, wait, I think there's actually a second filter in the debugfs one that gives you even more expanded ascii
<ktemkin>
it's been a while, for reasons of my sanity~
<whitequark>
* The magic limit was calculated so that it allows the monitoring
<whitequark>
* which presumably drives the bus, gets to hog CPU, yet we collect our data.
<whitequark>
* application to pick data once in two ticks. This way, another application,
<whitequark>
* enormous overhead built into the bus protocol, so we need about 1000 KB.
<whitequark>
* If HZ is 100, a 480 mbit/s bus drives 614 KB every jiffy. USB has an
<whitequark>
*
<whitequark>
* This is still too much for most cases, where we just snoop a few
<whitequark>
* descriptor fetches for enumeration. So, the default is a "reasonable"
<whitequark>
* amount for systems with HZ=250 and incomplete bus saturation.
<whitequark>
*
<whitequark>
* XXX What about multi-megabyte URBs which take minutes to transfer?
* whitequark
stares
<whitequark>
this is a good start
Foxyloxy has joined #glasgow
<whitequark>
i am both disturbed and relieved by the discovery that the linux kernel devs have the exact same kind of stupid solutions for stupid usb problems that i had to invent for glasgow
<whitequark>
even the buffer sizes are almost the same lmao
<russss>
kilobytes per jiffy is my new favourite measure of bandwidth
<ktemkin>
whitequark: yeah, it gets worse and worse as you start realizing the HCIs and HCDs do the same horrors at just progressively lower levels
<FFY00>
pyqt5 doesn't want to work with viewsb :/
<whitequark>
ontogeny recapitulates phylogeny
<whitequark>
.. or something along those lines
<ktemkin>
LUNA has been my catharsis, because I've tried to be horror-free where possible
<whitequark>
it seems really cleanly designed to me yeah
<ktemkin>
(can't be completely horror free, or I'd have skipped implmemeting USB)
<whitequark>
yuup
* whitequark
squints at mon_bin.c
<whitequark>
is this like... an adhoc implemnentation of a bipbuffer?
<whitequark>
/* not an issue unless there's a subtle bug in a HCD somewhere */
<ktemkin>
are you getting a kind of masochistic-schadenfreuden-satisfaction from peering into this abyss?
<whitequark>
think so
<whitequark>
it's certainly uh ... exceeding my expectations
<ktemkin>
mood
<ktemkin>
now imagine git cloning the linux kernel over airplane wifi in order to read this
<whitequark>
fun
<whitequark>
did the kernel really not have anything ring-buffer-like they could have used instead of writing this... thing.
<whitequark>
come on kernels are like 60% ring buffes by weight
<ktemkin>
there are lots of ring buffers
<whitequark>
ktemkin: did you ever discover how bizarrely, unexpectedly slow IPoTB is?
<ktemkin>
I'm sure the author thought they were all subtly wrong for this purpose and/or yoinked this code from another one of their projects
<ktemkin>
whitequark: no; I haven't tried it
<whitequark>
so TBT3 is 40 Gbps per direction, right?
<whitequark>
IPoTB is 10 Gbps at *best* and it's *shared between RX and TX*. and it's not the kernel that's the bottleneck.
<whitequark>
i haven't personally investigated it in detail, but i've been told that this is because IPoTB doesn't exist
<whitequark>
like, it looks like a pair of ring buffers, if you don't look too closely
<whitequark>
if you do look too closely you discover that the TBT controllers are just using each other in basically NTB mode
<ktemkin>
I've been trying not to pay too much attention to thunderbolt, even though USB4 is going to force that kind of horror at me
<whitequark>
which means that 3/4 of the bus bandwidth is spent waiting for posted writes or something like that
<whitequark>
like, i'm fairly sure that an IPoTB link is slower than the link you'd get if you took two TBT-PCIe bridges and put a NIC in each and then connected them with a DAC
<ktemkin>
I'm guessing this definitely logically followed Apple creating some gods-damned initial proprietary implementation that works iff you trust the two devices to DMA into each other
<whitequark>
i'm not actually sure that it works any better on apple hw
<ktemkin>
I'm not sure said thing made it out of Apple
<ktemkin>
... maybe I'll ask
<whitequark>
if you google for "apple ipotb" you get my twitter on second page, which is a pretty good indication of how popular ipotb is
* whitequark
reads the replies to that tweet
<whitequark>
ok you know, it might actually not be IPoTB but my laptop. possibly.
<ktemkin>
"I think there is a world market for maybe 10Gbps." -- Thomas J. Watson, probably
<whitequark>
lol
<whitequark>
this is an accurate representation of the design process that led to XPS 13
<whitequark>
(it has only two lanes connected to the TBT controller, which caused me no shortage of grief)
<whitequark>
personally, i think my favorite part of TBT3 is its "DROM", which is an I2C thing similar to EDID
<whitequark>
as far as i figured out, to read the switch configuration on every hop, the kernel bitbangs an I2C EEPROM over GPIO over Thunderbolt something or the other
<whitequark>
but the thing is, none of the Thunderbolt devices have any I2C EEPROMs on them. that data is stored in the same SPI flash as the controller firmware. so the controller reverse-bitbangs an I2C EEPROM in response.
<ktemkin>
beautiful
<whitequark>
same energy as that protocol for lighting control over 1149.1 over 1149.7 over a proprietary analog single-wire encapsulation
<ktemkin>
it's your JTAG-over-single-wire tweet all over agai--
<whitequark>
lmao
<ktemkin>
gotta encapsulate those encapsulations
<ktemkin>
even when the encapsulations add no value
<whitequark>
by 2050, every computer bus would have at least 100 Gbps of bandwidth, 80 of which will be spent bitbanging USB3 to control three RGB LEDs
<whitequark>
and by "bitbanging" i mean "generating waveforms with preemphasis applied in software to feed to that sweet high-speed SDR we have replaced every SERDES with"
<hl>
wonder if that lighting control JTAG was ever deployed in the wild
<whitequark>
hl: the patent goes into a really bothersome amount of detail
<hl>
whitequark: idly imagining a design involving multiple MCUs in which all but one are unprogrammed and the master just uses the others as an I/O expander via JTAG
<whitequark>
hl: see, this is why i want to find a device (any device) with JTAG-AP
<whitequark>
so i could do BSCAN over BSCAN over JTAG-AP over SWD
<whitequark>
so far i have only found this mediatek tablet, which does advertise JTAG-AP (without anything connected to it), as well as a lot of other bizarre and seemingly impossible stuff
<whitequark>
i mean the vendor insists JTAG is not bonded out in that SoC
<whitequark>
which was fun to hear after i spent several days using it to test all the failure code paths in the glasgow applet
<whitequark>
i even managed to dump a few dozen KB from a MEM-AP that insists that it is connected to AXI4
<whitequark>
as for the core debug, i'm not sure whether it's catastrophically broken, fused off, or both. the tablet isn't production fused but that's only half the story
<whitequark>
it sure is interesting to see AP#0 read all zeroes, and AP#3 always set STICKYERR after some wait cycles, even if you are just trying to read IDR
<whitequark>
(it sets STICKYERR for any APACC read)
<whitequark>
well, at least, i figured out why i couldn't get openocd to debug the core
<whitequark>
you know, i kinda feel like setting up a JTAG-based CTF
<whitequark>
where each stage is an increasingly broken device and you have to tunnel your scans through them all in sequence
<ktemkin>
lol
<whitequark>
if you manage to get a shell on the first one in chain (which will obviously be a Broadcom MIPS EJTAG v1.x router), you'll find some BSDLs
<whitequark>
and i think it must also include something by Renesas
<whitequark>
terminated, obviously, on MSP430 SBW
<whitequark>
maybe a board level challenge somewhere in the middle where you need to find a GPIO that pulls the TRST# of the next device down
<whitequark>
(gotta put those BSDLs to good use right?)
<ktemkin>
this sounds like it'd requrie a lot of real hardware, and thus a difficult CTF to run
<ktemkin>
~~but if you do ever want to actually run it I can get people do provide the things and e.g. do the physical manifestation at a conference for you~~
<ktemkin>
also: who called it "glasgow revC2" and not "glasgow rev-USB-C"
<whitequark>
i mean, i might! i'll probably like... need to do a lot of glasgow development first, because i have to make sure that the challenge is, well, feasible
<whitequark>
physically feasible.
<electronic_eel_>
ktemkin: by the time we finish Glasgow revD0, the usb d connector will be out (one plug and now 237 ways to create spec-conforming cables)
electronic_eel_ is now known as electronic_eel
<ktemkin>
whitequark: well, if at any point you want me to put you in contact with the people who run CTFs at various conferences in such a way as to have them do your bidding without expecting much of _you_, lmk
<ktemkin>
a lot of them owe me favors >.>
<whitequark>
:3
<whitequark>
will do
<whitequark>
tbh the only part i'm *really* concerned about is making it fun rather than like. virtually impossible
<whitequark>
i know i'm probably underestimating ctfers but still
<ktemkin>
as long as there are little bits hidden along the way, it'll be fun even if they only get like one or two flags
* whitequark
writes down: "the router has to be little endian"
<ktemkin>
lol
<Qyriad>
lol
<whitequark>
i've never found the idea of *playing* a CTF particularly fun, but *making* one sounds pretty appealing
<whitequark>
(my brain, reading this sentence, apparently: "cosplaying a CTF")
<d1b2>
<esden> @whitequark "I just play a CTFer on the internet." 😄
<whitequark>
ha
<ktemkin>
I did a CTF exactly once
<ktemkin>
I accidentally won and it was horrible
<whitequark>
did it feel exactly like work?
<ktemkin>
more or less
<ktemkin>
and then I accidentally won a bunch of my own products as a prize which I had to give away
<whitequark>
oh, i remember that story
<whitequark>
you know, now that i think about it, i worked with more than one programming interface that could be conceivably classified as a CTF
<whitequark>
remember that time i really wanted to have in-circuit debugging for nrf24le1 and so i found the verilog sources for thev 8051 core they used on pudn based on the one datasheet page they spent talkign about debug?
<whitequark>
the debug probe worked just fine, too
<whitequark>
at which point i discovered there are no open source 8051 remote debugger frontends
<d1b2>
<TiltMeSenpai> wait actually, does gcc use the fact that 8051 registers are memory mapped
<d1b2>
<geo> i got to use symbiyosys to solve a ctf challenge the other day which was kinda fun
<d1b2>
<TiltMeSenpai> or if I were to try and write an 8051 core, could I get away with like... just not implementing the memory map
<whitequark>
you can't push r0 without having it mmapped
<whitequark>
look at the encoding
<d1b2>
<TiltMeSenpai> ah, ok
<d1b2>
<TiltMeSenpai> I did an 8080 core minus DAA in nmigen, I was also thinking about doing an 8051 core but I didn't really want to do the memory mapping
<whitequark>
i kinda want to write a 8051 core in a very specific way that i'd rather not talk until i write it
<whitequark>
not secret i just feel like it
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] electroniceel pushed 1 commit to wip-revC2 [+0/-0/±2] https://git.io/JkSev
<gruetzkopf>
i might actually have a use for an 8080 core
<gruetzkopf>
and i don't think the codebase contains DAA
<d1b2>
<TiltMeSenpai> it works but it's not good imo
<d1b2>
<TiltMeSenpai> also the bus isn't good
<gruetzkopf>
i might have to build my own anyway
<gruetzkopf>
and lie to the system being emulated a fair bit
bvernoux has quit [Quit: Leaving]
<gruetzkopf>
(them being 2-out-of-2 run-in-lockstep machines)
<electronic_eel>
esden: i just looked at tvs diodes that would work for replacing the CDSOD323-T36S because of the sourcing problems
<electronic_eel>
i didn't find anything else that would fit in the same footprint unfortunately
<electronic_eel>
but when we go to sot-23 this seems to be quite common
<electronic_eel>
i found these parts in sot-23 that would all work: ESDA37W GSOT36C-G3-08 SM36T1G CDSOT23-T36C
<electronic_eel>
that is 4 parts from 4 manufacturers, i don't think we'll be running into problems there soon
<electronic_eel>
this seems to be a common value/characteristic for automotive, all of the manufacturers also have a automotive qualified version of these products available
<electronic_eel>
these are labeled as "bidirectional". in this case it means that it is a common anode configuration, so you can either use them uni or bidi
<electronic_eel>
but these are much better available than anything that is true unidirectional
<electronic_eel>
i think i should be able to squeeze in sot-23
<electronic_eel>
for port b it is going to be a bit tight with the pullup/down bridging headers, but it should work
<electronic_eel>
esden: i'd like your feedback about this change before i go messing with the layout
<esden>
I am very unhappy if we need to change the footprint to something else at this point... some footprint adjustments are fine but completely replacing the footprint means that if someone already has the part in question won't be able to use it.
<esden>
In my opinion changing to something else is going too far. But I am curious what whitequark thinks.
<electronic_eel>
hmm, has the part but won't be able to use it? i don't really understand this case
<esden>
The lesson learned here, we have to bu much much more vigilant in the future to assure parts are commonly available.
<electronic_eel>
you mean someone stocked the parts, but want to wait ordering the boards?
<esden>
Especially if we reuse a part "used in another project"
<esden>
Yes or someone who wants to get an updated board... like greg for example.
<electronic_eel>
for a small run i don't see a problem. you can very well solder a SOD-323 diode onto a SOT-23 footprint
<esden>
Especially this is going even beyond the bending on the rules of revision naming.
<electronic_eel>
it is just manual placement. only with a pnp this will become a problem
<esden>
I think if we change the footprint there we really aught to bump the revision to revC3
<esden>
As then the board is not compatible with revC2 any more.
<electronic_eel>
now the alternatives i see a) wait till march and hope mouser then really gets enough of the CDSOD323-T36S for us b) change to a sot-23 footprint, calling it revC3 or whatever c) use a lower voltage tvs that will reduce the max voltage capability of the adc
<esden>
I am still waiting for the quote from Arrow. They have the part in question even in stock. So they might have much less of an issue sourcing the part.
<electronic_eel>
ok, so then we can postpone a decision until you get the quote
<whitequark>
do we really *need* 40 V capability on Vsense?
<whitequark>
like, yes, i entirely agree that it's cool
<electronic_eel>
the next lower voltage is 24v
<whitequark>
that's still plenty, imo
<electronic_eel>
as 24v is very common, i'd prefer to be able to go a bit above it, like 30v would be really nice
<electronic_eel>
that would also match very well with my protection board
<whitequark>
do we really want to go out of our way (up to minor conflicts late into production schedule) to let someone use a $200 device without a screen as a less convenient voltmeter than anything you can get for $5?
<whitequark>
hrm, the protection board is more convincing
<whitequark>
personally, i think we should stop fussing over the board not being quite perfect enough and finally get it done
<whitequark>
i think it's been more than a year since i first talked to esden?
<electronic_eel>
i don't see it as a multimeter replacement. it is more being able to sense that some power rail is there from something you already have hooked into your automation/scripts
<whitequark>
look, people are so desperate for production they are pulling gerbers out of revC2
<whitequark>
*wip-revC2
<whitequark>
i concur with esden, this is becoming a document control nightmare
<whitequark>
well, on top of it just taking way too much time in first place
<whitequark>
that aside
<whitequark>
what would be the impact on your protection board?
<electronic_eel>
i haven't really thought the vsense-protection through with less voltage since we setteled on the ina233
<whitequark>
what happens if someone plugs your protection board into revC1?
<whitequark>
(and puts a high voltage there)
<electronic_eel>
the protection mechanism of the regular ios will cost some adc accuracy
<electronic_eel>
re protection for revC1 - there is a conflict between protecting revC1 from anything above ~6v and allowing revC2 to sense up to 36v
<electronic_eel>
the best would be if you could select the wanted protection voltage with a dip switch or something
<whitequark>
i see
<electronic_eel>
if i keep the same mechanism as for the regular ios (the depletion fets) then it would be just a changed resistor value. this is something that could very well be done with a dip switch, jumper or similar
<electronic_eel>
but this mechanism will cost adc accuracy. i have to actually fully design this part of the schematics to be able to estimate how much
<FFY00>
whitequark, Qyriad, I am looking at the exception issue and it seems that when using the TUI we are not receiving any exception when for eg. we don't have permission for usbmon
<electronic_eel>
i haven't actually worked on the protection board for some time. there was the test jig pcb and then revC2 in the way...
<FFY00>
a bit weird
<Qyriad>
what do you mean by "receiving" exceptions?
<FFY00>
handle_exceptions is never getting called
<FFY00>
nvm, I am so dumb
<FFY00>
god
<FFY00>
haaa
<electronic_eel>
whitequark: actually i just re thought more about it - the depletion fet protection method won't really work for anything above ~ 5v. because i need to provide a rail with the max. allowed voltage. so i'd need a stepup to create 24v if we'd used the 24v tvs. that is not really practical. so all other pins would be protected against 30v, the vsense just to 24v
<whitequark>
i see
<whitequark>
ok, let's wait for arrow
<whitequark>
Qyriad: ok, i htink i vaguely understand urwid now
<Qyriad>
I'm sorry for your loss
<whitequark>
lmao
<FFY00>
TBH it could be worse
<whitequark>
well yes we could have been working with USB
<whitequark>
hang on *presses hand to ear*
<d1b2>
<DX-MON> chortles in her USB madness
<whitequark>
the really cursed part is that i'm a lot less proficient with USB than people assume
<whitequark>
if nothing else, it means that i've yet to encounter most of the horror
<Qyriad>
same, except even more so
<Qyriad>
(as in, I'm even less proficient in USB, both than you and than people assume of me)
<d1b2>
<DX-MON> I'm having to re-learn so much of how USB "works" that I'm in the same boat, only sporting a massive headache too as my brain tries (badly) to wrap itself around how the hell the EP0 process works
<FFY00>
I've managed to keep myself away from most of USB
<d1b2>
<DX-MON> non-control EPs are fine.. I got that.. but the setup machinary.. ahhhhh
<whitequark>
so naturally it's also the reason why i am fixing viewsb
<whitequark>
i think once i figure out wtf is up with the tree navigation widget and the arrow keys i'll officially declare it ready
<whitequark>
FFY00: have you figured out what's up with exceptions?
<FFY00>
yeah
<d1b2>
<DX-MON> I look forward to being able to point it at my projects with impunity so I can figure out how I derped at USB EP0 this time
<FFY00>
we are not handling them
<FFY00>
:P
<FFY00>
we need to specifically dispatch them in the TUI loop
<whitequark>
oic
<whitequark>
honestly i would settle for a crash
<whitequark>
that like... prints the exception
<FFY00>
I had forgotten that each backend is supposed to do that themselves
<FFY00>
ah
<whitequark>
like, i'm on board with a nice TUI window. but i'd really like to have a crash first
<FFY00>
but this is only for backend exceptions
<whitequark>
think you can cook up something that can be merged?
<whitequark>
hmm
<FFY00>
that's what I am doing ;)
<whitequark>
sweet
<FFY00>
fighting TUI to show a pop up with the exception
<whitequark>
regarding the hang, i think the problem is that i don't have enough usb traffic
<whitequark>
because the moment i get *any* packets viewsb instantly unhangs
<electronic_eel>
does anybody know of a better text ui lib for python than urwid? some years ago i used newt in c++ and it was ok-ish for simple text menus, haven't done text uis since then
<whitequark>
(this is after you quit, and after urwid restores the screen, but before viewsb returns control to shell)
<Qyriad>
wait wait, *after* it quits it hangs?? Until you get usb data?m
<whitequark>
if you're using python-libusb1 i might even know what you're hitting
<Qyriad>
okay, I clearly need to spend more time on the tui frontend
<Qyriad>
that depends on the backend
<whitequark>
usbmon
<whitequark>
... oh
<whitequark>
i'm dumb.
<Qyriad>
I don't *think* any backend uses python-libusb1, but usbmon definitely shouldn't since that's a file thing
<whitequark>
yeap
<Qyriad>
Ah, the read calls block without timeouts, don't they...
<Qyriad>
Maybe the right solution is just to forcibly terminate the backend and frontend processes from the analyzer process after all
<Qyriad>
I'll take a look at the usbmon/file backend and see if I can't get it to behave, though, since I really don't like that idea
<whitequark>
i would make a pipe and select on both the usbmon file and the pipe
<whitequark>
though if it's linux-only i think you *might* be able to do something with signals?
<Qyriad>
true, but implementing backend specific stuff in the analyzer-termination process sounds even worse
<whitequark>
don't make it backend-specific
<whitequark>
the selfpipe trick is a classic way of delivering asynchronous events to waiters
<whitequark>
well in this case not exactly selfpipe
<Qyriad>
I meant the signal solution
<whitequark>
oh
<Qyriad>
I can't really respond to the selfpipe thing since I apparently am not familiar enough with linux programming, but I'll take a look at it later when I'm working on ViewSB again
<whitequark>
right so signals obviously work bc i can interrupt it with ^C
<Qyriad>
Oh that works?
<Qyriad>
Like, that un-hangs?
<whitequark>
yeah
<Qyriad>
Well that's something, at least
<whitequark>
yeah it's not sitting in iowait
<whitequark>
(usbmon doesn't even have that...)
<Qyriad>
...my lack of Linux systems programming knowledge is really showing here, wow >.>
<whitequark>
hm
<whitequark>
why not just send them SIGTERM?
<whitequark>
this isn't forcibly terminating the backend since it can mask or catch the signal if it needs
<Qyriad>
ViewSB is supposed to be cross platform (...though I don't think anything works on Windows right now)
<whitequark>
you can send SIGTERM on windows
<Qyriad>
Oh!
<whitequark>
well... you can't, but the python abstraction layer is pretending that you can
<whitequark>
it sends something else, lemme check what
<whitequark>
is this really not documented?..
<Qyriad>
That might actually be a good idea, then, so long as I can get it to manage closing stuff properly (like telling Qt to shutdown or shutting down the backends), since iirc signals aren't thread safe in the slightest
<whitequark>
python makes signals threadsafe
<Qyriad>
Wow, fancy
<whitequark>
signals are resynchronized using GIL and then sent to the main thread and nothing else
<Qyriad>
Thank you, Python
<whitequark>
otherwise instead of KeyboardInterrupt on ^C you'd get a dead process or a segfault
<whitequark>
not really optional
<Qyriad>
good point
<whitequark>
throwing a python exception when you receive a signal kinda requires you to be really careful about that signal
<whitequark>
no longjumping out of it or anything
<whitequark>
ok wow this is stupid
<whitequark>
windows implements sigterm. but you can only send it to yourself.
<electronic_eel>
lol
<whitequark>
it's a part of the C standard apparently
<whitequark>
and they are technically complying with it
<whitequark>
very microsoft solution, really
<whitequark>
so you can actually send SIGINT
<whitequark>
on linux, python resynchronizes it
<whitequark>
on windows, the way SIGINT works is it basically gets the kernel to CreateRemoteThread in the target process, which then executes the signal handler
<whitequark>
which i would like to note is an actually sane and reliable way to do asynchronous event delivery, unlike what unix does
<whitequark>
but the bottom line is the same, python resynchronizes it
<whitequark>
the *really* nasty thing about windows is its handling of terminals
<whitequark>
in short, the kernel implementation of anonymous pipes (yes, specifically anonymous) is such that a read from an anonymous pipe cannot be interrupted
<whitequark>
and guess what csrss gives you as stdin?
<whitequark>
and by "cannot be interrupted" i mean the kernel literally cannot do it. you cannot use overlapped reads/writes
<whitequark>
you cannot use CancelIo
<Qyriad>
please tell me you can at least set a timeout
<d1b2>
<DX-MON> you want windows to be any kind of sane?
<d1b2>
<DX-MON> the windows console system has been the bitter cause of much crying for me over the years
<Qyriad>
want ≠ expect
<d1b2>
<DX-MON> I'm currently angry with it that the ConPTY stuff is just.. broken.. when you want to set up a PTS to have your own process write to to then read back for the purposes of unit testing output functions
<d1b2>
<DX-MON> the whole mechanism is designed in such as way as you pretty much have to fork() (CreateProcessEx, b/c CreateProcess won't work for this)
<d1b2>
<DX-MON> and then set up extra pipes to IO the child with
<whitequark>
this is the point where i give up trying to explain windows semantics
<d1b2>
<DX-MON> on Linux, a process can open /dev/ptmx and then open the associated /dev/pts/xxx and voila.. no pain, no uggly.. two easy file handles that represent the two ends of a VTTY and which pass isatty() checks
<whitequark>
so basically the sitation is that you can catch ^C on Windows in an asyncio program like glasgow
<whitequark>
but doing something with that ^C if you are waiting on a Windows terminal is borderline impossible
<whitequark>
i *think* i spent several extremely frustrating days with it and managed to arrive at something that worked
<whitequark>
Qyriad: oh right, this is implied but worth pointing out explicitly: you cannot select or WSASelect on anonymous pipes either
<whitequark>
and you cannot WaitOnSingleObject on an anonymous pipe of course
<whitequark>
basically, the reason it works this way is very simple
<whitequark>
windows anonymous pipes do not behave like FIFOs
<whitequark>
they behave like synchronization points that let you exchange data
<d1b2>
<DX-MON> shudders
<whitequark>
i.e. until both processes park on the pipe, the pipe is neither readable nor writable, and then you have this atomic exchange, and it is back to being not readable or writable
<d1b2>
<DX-MON> that explains why they're so "fast"
<d1b2>
<DX-MON> but also such an unwieldy pain to be anywhere near
<whitequark>
and the kernel implementation is heavily tied into that model
<d1b2>
<DX-MON> memcpy() between the two process address spaces, near as, from the sounds?
<whitequark>
i think it's something like one IRP that gets submitted by one process and then handled by the other
<whitequark>
and it's strictly synchronous
<d1b2>
<DX-MON> hmm, ok
<whitequark>
unlike reads on something like a named pipe where you have one IRP on submission, another on completion
<whitequark>
basically, processes in windows waiting on a named pipe are like those linux processes stuck on iowait on a block device that hung
<whitequark>
the kernel literally does not have the capability to cancel the request
<d1b2>
<DX-MON> you mean an anon pipe? (you said named, I just want to be clear on which you meant)
<whitequark>
no, anon pipes and named pipes work differently
<whitequark>
you *can* wait on a named pipe, or do overlapped IO, or cancel IO
<whitequark>
but not on anonymous pipes
<d1b2>
<DX-MON> I mean that I read your analogy on how this kind of "pipe" works vs a Linux block device, but that sounds like you just described how the anon pipe works regarding it hanging like a hung block device
<whitequark>
yes, i compared the anon pipe hanging to a block device hanging
<whitequark>
so i think you read me correctly?
<d1b2>
<DX-MON> ok, you said "waiting on a named pipe" in the analogy, hence wanting the clarification
<Qyriad>
It sounds like the solution is don't use anonymous pipes, but I take it that's not an option?
<d1b2>
<DX-MON> 👍
<d1b2>
<DX-MON> windows is a mess
<whitequark>
you don't get to not use anonymous pipes, because the problem is csrss.exe
<Qyriad>
...right.
<whitequark>
well, it's conhost.exe now, and i vaguely recall something about microsoft caring about this?
<whitequark>
there is also another part of the problem
<whitequark>
which is even more depressing
<whitequark>
which is that you have ReadConsole, which isn't cancellable, and ReadConsoleInput, which forces you to implement a cooked terminal
<Qyriad>
oh no
<whitequark>
oh and
<whitequark>
have i mentioned that this thing about anonymous pipes?
<whitequark>
it's not a property of the *pipe*.
<whitequark>
it's somehow, inexplicably, a property of the *handle*.
<whitequark>
because anonymous pipes are a subset of named pipes.
<Qyriad>
can you cheat and get a handle to the underlying named pipe?
<whitequark>
ok you know, i give up. every time i have to work with this specific corner of windows, i have to page it in for literally hours
<Qyriad>
is that solved the way I'm suggesting? I must be missing something, then, since I'm mostly just seeing using `select()` to bypass a kqueue restriction
<ktemkin>
(I apologize for not being around for ViewSB-related discussion, but the brainfog-part of this sick kicked in a bit ago)
<whitequark>
and then i forget it the very next day
<whitequark>
Qyriad: disregard what i said, i'm not awake enough for anonymous pipes :s
<Qyriad>
yeah this is why I haven't touched viewsb on windows yet; I just don't want to add functionality to the general analyzer that specifically relies on *not* Windows
<whitequark>
ok look
<whitequark>
i'll gladly help you port it
<whitequark>
i ported glasgow. it works fine
<whitequark>
what i cannot promise you is that i'll be able to explain *why* it works
<whitequark>
because every time i think i understand why it breaks, it turns out that i'm wrong in some subtle but important way
<Qyriad>
That's perfectly fine but also if you're going to be doing major work on viewsb then ktemkin and I are going to get you paid for it =P
<whitequark>
well i'm not going to refuse lol
<ktemkin>
Qyriad: is your contribution to “ktemkin and I” that you’d poke me to do the details? =P