ticalc.link
ticalc.link copied to clipboard
Can't Connect to a Renamed Calculator. Add Manual Override?
ticalc.link appears to determine what calculator is connected by checking its name. Unfortunately, this means that people such as reesericci and I cannot use our TI-84 Plus CE calculators with ticalc.link because we've renamed them to something other than the default 'TI-84 Plus CE' using CERMASTR.
Is there another way to identify what calculator is connected such as the OS version? Could there be an 'advanced' tab that lets the user manually select what calculator they are using?
This is a good point as I had to change my calc name back to use ticalc.link.
Do your renamed calculators work with TILP (libticables) ?
Good point @TheLastMillennial... The "good" news is that the way we detect the device needs a complete overhaul anyway 🙈
We currently use USB properties to detect which type of device we're connected to. Primarily vendor ID and product ID, but for some devices these IDs have been reused by Texas Instruments (so the same ID can indicate different devices). In those cases we also look at the device name to distinguish between the different possible devices (which breaks for you). Actually, when I wrote the code I wasn't aware you're able to change the name of these things 😂
Anyway, this mechanism doesn't play nice with things like the GraphLink cable, since there the USB properties of the device don't tell us anything about the calculator on the other end of it. So to support those we'll need to explicitly ask the calculator "who are you?" through the TI protocol anyway. Makes sense to do the same thing with the calculators sharing a USB product ID.
However, this is not something I'm planning on doing very soon. So yeah, maybe an advanced option "treat like X" would be a good idea in the interim.
There's a middle ground for probing calculators, though, and that's why I'd like to know whether the renamed calculators work with TILP (libticables) :)
Following a suggestion by @debrouxl , I installed TILP and discovered TILP will correctly recognize my renamed calculator as a TI-84 Plus CE. Perhaps ticalc.link can adopt TILP's method of identifying calculators?
Good, thanks for the test. So yeah, ticalc-usb definitely should adopt the libticalcs probing method, even if probably implemented differently, based on callbacks.
libticables started using the USB version number as a fallback method for USB-level model detection in 2015, see translate_usb_device_info
in https://github.com/debrouxl/tilibs/blob/experimental2/libticables/trunk/src/probe.cc .
Another user was impacted by this "limitation", but is nowadays more problematic, because now:
- the latest CE OS (5.7) not show the custom calculator name anymore in any screen (potentially leading to think the name was back to the default while it's not),
- CERMASTR isn't yet compatible with the latest OS (TI fixing the flaws needed to make it work) so people can't change the name back to the default.
Any hope of using the bcdVersion
field like @debrouxl said, at least as a fallback when the model name is unrecognized? I checked in the WebUSB things, it seems to be available.
Thanks :)
Thanks for the update.
I've so far been looking at if we can just remove the dependency on the device name completely, only using the vendorId
and deviceId
. But that's not possible, unfortunately. I think your idea to allow users to select their device type when the deviceId
matches, but the name doesn't, is a pretty good one. I've been reluctant to implement a "treat like X" feature because it adds clutter to the interface for everyone, but your idea would solve that issue.
I'll take another look.
Right, only displaying that "manual selection/override" when the name doesn't match would solve the issue for the people who have it while not changing the current interface for anyone else, so I suppose it could work. Then again, the bcdVersion
field should also work just fine to be able to select the correct calculator model, if we want to avoid any GUI-based override. And as far as I know, nobody has bothered changing that on their calculator 😆
But I would need to communicate with the device first to ask it for the bcdVersion
, right..?
Well it's part of the descriptor properties that you can read once you're connected with the VID/PID filter, not something TI-specific. Should work fine?
Should work fine, indeed.
Ah, okay! Didn't know that. So the value of bcdVersion
says something about the connected calculator? That's a bit confusing given the documentation you linked:
20 | bcdVersion | 2 | BCD | Protocol version supported. Must be set to 0x0100. |
---|
So is bcdVersion
what's indicated with usbinfo->version
in probe.cc?
The0x100
value is specifically when "A device announces support for the WebUSB command set". Which isn't going to be the case anyway here, TI just uses different values that allow to distinguish the model, so that's nice.
Looks like it's the version
field in probe.cc, yes.
Looks like you guys are comparing the device name first, then fall back to the version to detect the same thing twice but through different methods?
else if (usbinfo->pid == PID_TI84P_SE)
{
info->family = CABLE_FAMILY_USB_TI8X;
if (!strcmp(usbinfo->product_str, "TI-84 Plus Silver Edition"))
{
info->variant = CABLE_VARIANT_TI84PSE;
}
else if (!strcmp(usbinfo->product_str, "TI-84 Plus C Silver Edition"))
{
info->variant = CABLE_VARIANT_TI84PCSE;
}
// [...]
else if (usbinfo->version <= 0x0110)
{
info->variant = CABLE_VARIANT_TI84PSE;
}
else if (usbinfo->version == 0x0120)
{
info->variant = CABLE_VARIANT_TI84PCSE;
}
Yep, the name is supposed to me more specific, but may not always be available (corrupted/invalid... certificate) so the version acts as a fallback. I don't know if only relying on the version is enough for what ticalc.link wants to support. Maybe @debrouxl can weigh in?
I suppose I could just do the same. I'm already checking for the name, I can add the version as a fallback too. But it will complicate the code and make it a little less straight forward.
I have quite a few things to work on for ticalc.link / ticalc-usb piled up now. I'll see if I can find some time to work on this over the holidays, between my other projects. I have a few too many fun projects going on 😂
i have the same problem