ticalc.link icon indicating copy to clipboard operation
ticalc.link copied to clipboard

Can't Connect to a Renamed Calculator. Add Manual Override?

Open TheLastMillennial opened this issue 3 years ago • 18 comments

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?

TheLastMillennial avatar Sep 26 '21 18:09 TheLastMillennial

This is a good point as I had to change my calc name back to use ticalc.link.

reesericci avatar Sep 26 '21 19:09 reesericci

Do your renamed calculators work with TILP (libticables) ?

debrouxl avatar Sep 26 '21 19:09 debrouxl

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.

Timendus avatar Sep 27 '21 12:09 Timendus

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) :)

debrouxl avatar Sep 27 '21 13:09 debrouxl

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?

TheLastMillennial avatar Nov 16 '21 22:11 TheLastMillennial

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 .

debrouxl avatar Nov 16 '21 22:11 debrouxl

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 :)

adriweb avatar Dec 07 '21 09:12 adriweb

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.

Timendus avatar Dec 20 '21 16:12 Timendus

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 😆

adriweb avatar Dec 20 '21 17:12 adriweb

But I would need to communicate with the device first to ask it for the bcdVersion, right..?

Timendus avatar Dec 22 '21 16:12 Timendus

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?

adriweb avatar Dec 22 '21 16:12 adriweb

Should work fine, indeed.

debrouxl avatar Dec 22 '21 16:12 debrouxl

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?

Timendus avatar Dec 23 '21 13:12 Timendus

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.

adriweb avatar Dec 23 '21 13:12 adriweb

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;
		}

Timendus avatar Dec 23 '21 13:12 Timendus

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?

adriweb avatar Dec 23 '21 13:12 adriweb

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 😂

Timendus avatar Dec 23 '21 13:12 Timendus

i have the same problem

InvalidJake avatar Apr 29 '22 20:04 InvalidJake