<rqou>
unfortunately, i believe such a codeless kext will break the official greenpak designer
<rqou>
the driver situation on macos sucks
eduardo__ has quit [Ping timeout: 246 seconds]
scrts has quit [Ping timeout: 240 seconds]
<azonenberg>
Breaking the official flow is a no-go for now
scrts has joined ##openfpga
<rqou>
hrm
<rqou>
well, it is in contrib/
<rqou>
:P
<cyrozap>
rqou: You can still disable kext signature enforcement via an NVRAM setting on OS X, right?
<rqou>
yes
<rqou>
but (afaik, untested) the official greenpak tools go through the hid api
<rqou>
so blocking the hid driver from matching will make that stop working and apparently azonenberg doesn't like this solution
<cyrozap>
If it's available via HID, why do you need to block it?
<rqou>
because on macos libusb doesn't know how to go through the hid layer
<rqou>
it goes through some lower iokit layer
<rqou>
unlike on windows, where libusb _can_ go through the hid layer
<rqou>
so this is a libusb problem
<cyrozap>
Then use hidapi...?
<rqou>
patches welcome :P
<rqou>
anyways, with the hostile takeover and everything i'm definitely not touching libusb
<cyrozap>
What exactly do I need to patch? Is there an issue #?
<rqou>
you would have to replace gpdevboard's calls to libusb to use hidapi instead
<cyrozap>
Oh, that's easy
<cyrozap>
I did that in the KitProg driver a while ago
<azonenberg>
cyrozap: How about you work on that then? Make a PR
<azonenberg>
I'll test that it doesn't break linux, but have no way to test on mac so i'll take your word for it
<rqou>
this also avoids the apple tax, which is nice
<azonenberg>
rqou: can you test his patches dont break windows?
<rqou>
i can test windows and mac
<azonenberg>
excellent
<azonenberg>
we have our bases covered then
<azonenberg>
cyrozap: we'll take a PR any time you have it ready :)
<rqou>
iceprog will still be a PITA though
<rqou>
it uses FTDI
<azonenberg>
That's not my problem :)
<rqou>
i still need to test iceprog actually works on windows
<cyrozap>
azonenberg: Sure, but I can't test at all since I don't have a dev board, so I'll have to rely on you guys.
<azonenberg>
jtaghal is another can of worms entirely, as it does make FTDI calls, but that's not something i will be officially supporting on osx for a while
<azonenberg>
cyrozap: You should work on that at some point :)
<azonenberg>
But sure, for now we can test
<rqou>
iceprog works on osx if you unload the ftdi kext
<rqou>
but iceprog is a huge mess on windows
<cyrozap>
azonenberg: Would you rather I fork into my own repo, or just make a branch on the main project?
<azonenberg>
if you switch halfway through you get them getting new device IDs and getting all out of whack
<rqou>
the board boots in "white" mode and is switched into "orange" mode
<azonenberg>
this is one of the reasons why all of my ftdi jtag boards have eeproms with unique serial numbers
<rqou>
but imagine the extra $0.01 that will cost! :P
<azonenberg>
lol
<rqou>
azonenberg: so what are 0f0f:0001 to 0005?
<rqou>
some other dev boards?
<azonenberg>
Good question
<azonenberg>
we havent seen them in the wild
<azonenberg>
ooh my usb.ids entries for the devkit got added finally?
<rqou>
hmm i wonder why the 8006 mode can't have its report descriptor read
<azonenberg>
i think its like a minimalistic bootloader or something
<cyrozap>
So, unfortunately, if we switch to hidapi, you won't be able to individually address the dev boards by enumeration number. The hid_open function only takes VID, PID, and serial as parameters.
<azonenberg>
Hmm
<azonenberg>
So multiple devkits are a no-no on osx for the time being?
<azonenberg>
how about you implement it anyway, and just return fail if you ask for an index other than zero
<cyrozap>
For any OS if we switch entirely to hidapi.
<azonenberg>
I was not planning that
<azonenberg>
i was planning ifdefs for osx
<cyrozap>
Oh, I see
<azonenberg>
Since libusb is the preferable solution on windows and linux
<cyrozap>
Really?
<azonenberg>
Multiple devkit support is a must on any platform that can handle it
<azonenberg>
i have two in front of me right now and would prefer 3-4 if i could get them
<rqou>
hmm i wonder what the native silego software does?
<azonenberg>
they may not support multiple devkits? :p
<azonenberg>
but worth checking
<azonenberg>
So unless there's a way to do hidapi for multiple indistinguishable devices
<azonenberg>
it's a last resort iff we can't do the job with libusb
<rqou>
unfortunately i can't test multiple devkits because i only have one
<cyrozap>
Oh, lol, I'm dumb
<cyrozap>
hid_open is a shortcut function
<azonenberg>
lol
<azonenberg>
So there is a way to do multiple devices?
<rqou>
feel free to send me more devkits :P
<azonenberg>
In that case i would not be opposed to a full switchover
<cyrozap>
You can enumerate manually and get libusb-equivalent functionality
<azonenberg>
if it works on all 3 platforms and doesn't degrade functionality
<cyrozap>
Yeah, HID should be better for Windows, too, since you won't need to associate any driver like you need to with libusb (I think)
<rqou>
<troll>only 3 platforms? what about netbsd toasters? what about haiku?</troll> :P
<rqou>
you don't need to associate a driver on windows
<cyrozap>
I believe hidapi actually works on BSD as well
<rqou>
libusb has special logic to go through the windows hid layer
<rqou>
cyrozap: semi-troll: android?
<cyrozap>
I just checked, it supports FreeBSD in addition to OS X and Linux
<cyrozap>
Android runs Linux, so yes :P
<rqou>
without rooting?
<azonenberg>
i have worked on client products that used... libusb, i think? or was it ftdi? on android
<azonenberg>
i dont think they were rooted
<rqou>
<troll>iOS?</troll>
<cyrozap>
...maybe? hidapi has both an hidraw and a libusb backend for Linux, and it uses the native HID apis on OS X and Windows.
<cyrozap>
^ that maybe was regarding rootless Android
<rqou>
<extra troll>vxWorks?</extra troll>
<rqou>
Phar Lap ETS? :P :P :P
<rqou>
azonenberg: genuinely curious if you've seen a client using phar lap ets :P
<azonenberg>
not that i can think of
<rqou>
apparently phar lap has been around for forever
<rqou>
but right now i've only ever heard of NI using them
<cyrozap>
Oh, wait
<cyrozap>
Nope, never mind
<cyrozap>
I was about to say that actually I'm a double-idiot, because I misread the docs twice and you can't actually select devices manually even if you enumerate all of them yourself, but actually you _can_ select them individually, but by a platform-specific _path_ instead of an interface number.
<cyrozap>
This project is a rollercoaster of emotions!
<rqou>
or you can grab my kext from the pull request :P
* cyrozap
resumes work
<cyrozap>
rqou: Why? I can implement "select by number" by enumerating that list of paths.
<rqou>
yeah your method is definitely cleaner
<azonenberg>
cyrozap, rqou: ideally
<azonenberg>
if your method allows a device to be switch modes and re-enumerate
<azonenberg>
and not change index
<azonenberg>
you can close #71
<azonenberg>
my current code handles that poorly
<rqou>
such as not realizing usleep can return EINVAL? :P :P
<rqou>
although tbh i didn't realize usleep was allowed to return EINVAL either :P
<azonenberg>
um, yeah lol
digshadow has quit [Quit: Leaving.]
fpgacraft1_ has joined ##openfpga
fpgacraft2 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft1_ is now known as fpgacraft1
fpgacraft1 has quit [Quit: ZNC 1.7.x-git-709-1bb0199 - http://znc.in]
fpgacraft2 has joined ##openfpga
azonenberg_work has quit [Ping timeout: 256 seconds]
<azonenberg>
I didnt write most of that code so ask whitequark
<azonenberg>
from my perspective if it works and follow the general style, i'm happy
<rqou>
arrgh your code style is totally different :P
<azonenberg>
rqou: lol oh?
<cyrozap>
azonenberg: Oh, ok. I saw your name at the top of the file so I thought it was yours :P
<rqou>
a bunch of friends and I used to use a hacked-up Google style
<rqou>
basically only keeping the formatting rules and dropping anything about what you can actually write in the code
<azonenberg>
cyrozap: yeah thats the overall project header
<azonenberg>
rqou: At some point i'm going to try codifying more of my unwritten rules, as i think of them
<rqou>
but basically we were doing spaces only and open brackets on the same line
<azonenberg>
as a general rule i like to keep code simple and readable, comment more than strictly necessary
<azonenberg>
and i see
<azonenberg>
Yeah i learned with visual studio '98
<azonenberg>
(wow, is that really a nearly 20-year-old compiler? I feel old lol)
<rqou>
i kinda did too and was told that i was weird :P
<azonenberg>
Lol
<azonenberg>
i also learned on windows
<azonenberg>
where basically everyone did that
<azonenberg>
i'm a bit of an exception in the unix world
<rqou>
at least it's not gnu(?) weird half-indenting
<azonenberg>
lol
<rqou>
but yeah, your code style is strangely not-unixy :P
<azonenberg>
At some point i plan to add a verilog linter to either splash or yosys that enforces some of these rules
<azonenberg>
in particular the things like "always" blocks in verilog being either clocked or *
<azonenberg>
never explicit combinatorial sensitivity lists
<azonenberg>
and the mandatory default_nettype none
<rqou>
at least you don't use MFC-esque systems hungarian notation :P
<rqou>
m_lpcwstrFooName anybody? :P
<azonenberg>
Lol
<azonenberg>
yes i learned on MFC and never did that
<azonenberg>
the only thing i do is m_ and g_ prefixes
<azonenberg>
just to make it clear you're not working with a lcoal
<azonenberg>
local*
<rqou>
i've seen microsoft-style C code sarcastically described as "looking more like BASIC than C" because of all the typedefs :P
<azonenberg>
lol
<rqou>
BOOL, DWORD, LPARAM, WPARAM, etc. etc.
<jn__>
#define BEGIN {
scrts has quit [Ping timeout: 258 seconds]
<rqou>
and of course everybody's favorite portability nightmare LPCWSTR
<jn__>
long pointer to constant wide string!
<azonenberg>
lol
<rqou>
yeah, and now you've got a "wide" string
<rqou>
awesome (/s)
scrts has joined ##openfpga
<rqou>
i'm not sure what's worse, getting a "wide" string or a "char *"
<rqou>
where you have absolutely no idea what is in the "char *"
<azonenberg>
i thought windows char* was always 8-bit ascii using the default system code page?
<rqou>
is it?
<rqou>
why isn't it the "OEM" codepage? why isn't it UTF-8?
<azonenberg>
Lol
<azonenberg>
No idea, i never actually tried using anything more than 7 bit ascii
<lain>
>.>
<azonenberg>
all of my work with unicode has been utf8 on linux
<rqou>
so you know how people had to invent a "WTF-8" encoding to deal with malformed UTF-16?
<lain>
two words: backward compatibility
<azonenberg>
rqou: lool
<rqou>
i've been somewhat-seriously somewhat-jokingly discussing with my housemates on how to create something even better
<lain>
this all predates utf-whatever being used anywhere :P
<azonenberg>
i mean when i learned windows programming
<rqou>
basically the idea is to always allow you to concatenate any blob of bytes with any other blob of bytes
<rqou>
preferring to create mojibake rather than encoding errors
<azonenberg>
you had chars for en-us
<azonenberg>
and for anything else
<rqou>
the working name for this idea is "WTF-⑨" encoding :P
<azonenberg>
you had wchar_t which was one 16-bit code point each
<azonenberg>
and unicode had less than 64k code points
<azonenberg>
so it just worked
<lain>
if we just stop writing desktop apps in c/c++ we can solve this ;)
<rqou>
btw there is a specific reason why it's "WTF-⑨" and not "WTF-9" :P
<azonenberg>
not true utf16 (which i think ca nrepresent higher code points with multiple wchar_t's), literally one 16-bit code point each
<rqou>
but yeah, one of my worst pain points with writing python3 is that it requires me as the python programmer to have figured out what all of my weird external dependencies decided to do wrt encodings
<rqou>
rather than "blindly shuffle and/or concatenate byte blobs and see what happens"
<rqou>
which usually ends up producing the right answer by chance anyways
<rqou>
i think a lot of python3 complains would be solved if somebody created a "i don't know or care; just give me mojibake" encoding
kuldeep__ has quit [Read error: Connection reset by peer]
<rqou>
although i've heard that the python folks are slowly relenting because they realized that their "world is perfectly unicode" world is slowing python3 adoption
kuldeep__ has joined ##openfpga
scrts has quit [Ping timeout: 260 seconds]
scrts has joined ##openfpga
carl0s has quit [Read error: Connection reset by peer]
digshadow has quit [Quit: Leaving.]
carl0s has joined ##openfpga
cosmobird has joined ##openfpga
<rqou>
hey, is github really delayed at sending emails for anybody else?
<rqou>
although i'm still working on the documentation for it
<rqou>
documentation is so much work :P
kuldeep__ is now known as kuldeep
digshadow has quit [Ping timeout: 240 seconds]
<openfpga-github>
[openfpga] cyrozap opened pull request #79: Switch to hidapi (master...hidapi) https://git.io/vysND
digshadow has joined ##openfpga
<cyrozap>
Again, apologies for the giant diff--the actual functional changes are very small (mostly in src/gpdevboard/usb.cpp).
kuldeep has quit [Read error: Connection reset by peer]
<cyrozap>
azonenberg, rqou: Please test whenever you're able to. I've only checked that it can compile. :/
kuldeep has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has quit [Ping timeout: 256 seconds]
cosmobird has quit [Ping timeout: 240 seconds]
scrts has quit [Ping timeout: 260 seconds]
cosmobird has joined ##openfpga
scrts has joined ##openfpga
carl0s has quit [Quit: Leaving]
m_w has joined ##openfpga
m_w_ has joined ##openfpga
m_w has quit [Read error: Connection reset by peer]
m_w_ has quit [Client Quit]
promach has joined ##openfpga
m_w has joined ##openfpga
m_w has quit [Read error: Connection reset by peer]
m_w has joined ##openfpga
m_w has quit [Read error: Connection reset by peer]
Hootch has joined ##openfpga
<openfpga-github>
[openfpga] whitequark commented on issue #79: Why not just `typedef hid_device* hdevice;`? https://git.io/vyGTL
<whitequark>
rqou: that's an awful idea.
<whitequark>
broken code that can't into encodings needs to be fixed, and you're slowing down that process
<rqou>
but usually when it happens the wrongness already happened in code i _don't_ control
<rqou>
usually it's "this module being called via a FFI interface gave me a 'char *' of unknown encoding" or "the user gave me a byte sequence of unknown encoding"
<rqou>
and all I usually want to do with it is "give it back to some other FFI interface" or "put a reasonable approximation of it on the screen"
<rqou>
my WTF-⑨ idea shouldn't make anything any more wrong than it already is
<rqou>
rust's OsString is in theory better
<rqou>
but i've already seen libraries that incorrectly declare str for things that _should_ be OsString
<rqou>
so yeah, WTF-⑨ is supposed to be a not-especially-socially-responsible "not my problem" encoding that makes my quick scripts easier to write
<openfpga-github>
[openfpga] cyrozap commented on issue #79: I tried that originally, but I just got a bunch of compiler errors. Something about "hid_device*" not being a type. https://git.io/vyGkV
massi has joined ##openfpga
massi has joined ##openfpga
Hootch_Work has joined ##openfpga
Hootch has quit [Ping timeout: 260 seconds]
<openfpga-github>
[openfpga] whitequark commented on issue #79: Well which errors exactly? https://git.io/vyGIW
<openfpga-github>
[openfpga] whitequark commented on issue #79: This works for me:... https://git.io/vyGIV
<openfpga-github>
[openfpga] cyrozap commented on issue #79: I just pushed an amended version of that commit and it works now--not sure why it didn't before. https://git.io/vyGIN
digshadow has joined ##openfpga
<openfpga-github>
[openfpga] whitequark commented on issue #79: OK this is much better. Let me try it on the buildbot... https://git.io/vyGL2
<whitequark>
azonenberg: I just ran cyrozap's tree on the buildbot
<whitequark>
force build while setting repository
<whitequark>
this isn't done automatically like with travis because buildbot is not sandboxed and so you can effectively run arbitrary code you put there
kuldeep has quit [Read error: Connection reset by peer]
kuldeep has joined ##openfpga
<rqou>
so one problem with sublime text's "magic save everything" feature is that i end up with a bunch of random unsaved buffers and i have no idea if the information in them is useful anymore
<rqou>
obviously the solution is to just dump them all on pastebin and be done with it :P
<openfpga-github>
[openfpga] rqou commented on pull request #79 a2d3e27: So there is an obvious use-after-free here because you are using `cur_dev` but you've already called `hid_free_enumeration(devs);`. However, fixing this issue still doesn't make things work because mode switching just doesn't work for some reason and does nothing (Linux x64, hidapi-libusb). https://git.io/vyGB6
kuldeep has quit [Ping timeout: 256 seconds]
cosmobird has quit [Remote host closed the connection]
<openfpga-github>
[openfpga] rqou commented on issue #79: So a whole bunch of funny stuff seems to be going on here. First of all, the command to switch from "white" mode to "orange" mode doesn't seem to be a real HID report at all. It is just 64 bytes of 0 with a random 0x09 at offset 60. For whatever reason, the hidapi-libusb code [skips the first byte](https://github.com/signal11/hidapi/blob/master/libusb/hid.c#L1009) if the first byte of the buffer is
<openfpga-github>
[openfpga] rqou commented on issue #79: Er, `hid_get_indexed_string` just outright isn't implemented on the hidraw backend apparently. Not sure if this is worth fixing? https://git.io/vyGuI
<openfpga-github>
[openfpga] rqou commented on issue #79: Windows can switch from "white" to "orange" mode, but interactions in "orange" mode just result in `ERROR: Unexpected reply` and `ERROR: Fault condition detected during initial check, exiting`. Also, whitequark is probably going to tell me I'm doing it wrong, but getting cmake to statically link hidapi is immensely frustrating (er, more so than my usual build system butchery) because it requires se
kuldeep has joined ##openfpga
<openfpga-github>
[openfpga] whitequark commented on issue #79: > The only way I could get this to work is to hack the gpdevboard CMakeLists.txt to contain target_link_libraries(gpdevboard ${HIDAPI_LIBRARY} log setupapi). Previously I could get away with just dumping a large pile of -L and -framework options in CMAKE_EXE_LINKER_FLAGS.... https://git.io/vyGgT
<openfpga-github>
[openfpga] rqou commented on issue #79: But setupapi should only be linked on Windows, so somehow this needs fixing of some kind. https://git.io/vyGgm
<rqou>
great, hidapi requires me to install autocrap on osx
<rqou>
aand it doesn't work anyways
<openfpga-github>
[openfpga] whitequark commented on issue #79: `if(WIN32) https://git.io/vyG2S
<rqou>
and find on macos is weird/doesn't work either
marcus_c has quit [Ping timeout: 240 seconds]
<openfpga-github>
[openfpga] rqou commented on issue #79: Alright, prepending a 0x00 byte in `SendInterruptTransfer` seems to more-or-less fix things. You also need to include `<cstdlib>` for `wcstombs` on macOS.... https://git.io/vyGwq
<openfpga-github>
[openfpga] rqou commented on issue #79: cyrozap: Please verify that prepending a 0x00 (Report ID?) is indeed a proper fix and not a flaky hack. I'll test everything again tomorrow (later today). https://git.io/vyGws
wpwrak has quit [Read error: Connection reset by peer]
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
digshadow has quit [Ping timeout: 264 seconds]
promach has quit [Quit: Leaving]
clifford has joined ##openfpga
amclain has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
Bike has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
mifune has joined ##openfpga
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined ##openfpga
massi has quit [Quit: Leaving]
mifune has quit [Ping timeout: 258 seconds]
<rqou>
balrog: I don't care too much about those types of issues
<rqou>
I'm much more concerned with random +1/-1 being done to include/exclude report IDs
<rqou>
similar to what I did :P
<rqou>
there were a number of issues that contained various rounds of "there should be a +1/-1 here" "no there shouldn't" "yes there should" "hmm are you sure?"
<balrog>
rqou: an error function should be able to handle errors
<rqou>
I don't care that much because my programs tend to not have very functional error handling to start with :P
digshadow has joined ##openfpga
<lain>
what we're witnessing here is the difference between coding for fun and coding because expensive things rely upon it :P
<rqou>
right, I've yet to ship an actual USB product
<rqou>
so I can get away with "herp derp, try unplugging it and plugging it back in"
<lain>
;)
<rqou>
although tbh I've found that my firmware tends to get wedged less often than I've seen actual real products get wedged :P
<rqou>
"oh, you aborted a transaction? what's an 'abort?'" :P
digshadow has quit [Client Quit]
<lain>
yeahhhhhhh
azonenberg_work has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
<rqou>
whitequark: what's the correct way to get cmake to do "-framework IOKit" that isn't just dropping it into CMAKE_EXE_LINKER_FLAGS?
Hootch_Work has quit [Quit: Leaving]
carl0s has joined ##openfpga
digshadow has joined ##openfpga
<openfpga-github>
[openfpga] cyrozap commented on issue #79: @rqou Please try the latest patches and see if they fixed what they were supposed to. As for the libusb-backend-weirdness issue, can you please check if the patch below works? If it doesn't, that means the programmer is not ignoring the report ID byte and we'll have to use the hack you described.... https://git.io/vynJE
<openfpga-github>
[openfpga] cyrozap commented on issue #79: @rqou:... https://git.io/vynUm
Lord_Nightmare has quit [Ping timeout: 240 seconds]
<balrog>
(AMD Ryzen supports ECC in their desktop-class CPUs. They don't put it through full workstation testing but it's available)
Lord_Nightmare has joined ##openfpga
<azonenberg>
interesting
<rqou>
i mean, so does intel :P
<rqou>
skylake/kaby lake pentium/celeron have ecc enabled
<rqou>
but for some reason only with a server chipset
digshadow has quit [Ping timeout: 256 seconds]
<balrog>
AMD seems o be partly blaming compiler optimizations for lower than expected performance for some software
<rqou>
-march=broadwell -mtune=broadwell? :P
<balrog>
rqou: I'm not sure what kind of tuning GCC does normally for Intel's hyperthreading method
<balrog>
partly blaming prerelease motherboard bios and such
<balrog>
this is the first AMD microarchitecture with proper hyperthreading, not that weird "CMT" system
<rqou>
if (cpuid vendor name == GenuineIntel) { go fast} else { runs on a potato }
<rqou>
:P
<balrog>
rqou: intel was caught doing that in ICC
<rqou>
i mean, even windows did some of that in various parts of the bootstrap for x86_64
<rqou>
Via had some issues with it
<qu1j0t3>
There's a new official name for this technique: Volkswagening.
<rqou>
lol
<rqou>
i never really understood the shock and outrage at Volkswagen
<rqou>
i always just assumed that they were already cheating emissions benchmarks and that the standards would just be set to take that into account :P
<azonenberg_work>
volkswagening would be more like overclocking when you detect you're running SPEC