Did you mange to get it working ?

Hello,
Where can the firmware updates for the CAC-1504 be downloaded from?  There is a “Downloads” tab on the product page, but when I look there, this only seems to contain documentation.

My adapter is rev. A0-01.  I had problems getting it working when I first got it, and I eventually gave up, but from the posts here, it appears that there have been several revisions of firmware, and I would like to try the most recent.

Note: My problems were similar to the OP: monitor seems to be recognized via EDID but I get a black screen when trying to use 4k/60Hz.

Thanks!

Hello Drosky, 

please send an email to [email protected], you can just copy the above message into the email. Support can provide the firmware for you.

Thanks, I’ll do that.

I should also mention, in case it is relevant to the issue, that the black screen problem I was having only occurred in Linux.  In Windows 10, the adapter worked okay at 4k/60Hz.  Other people have apparently had these working in Linux, but since I only have one HDMI 2.0 monitor, and one computer with a USB-C displayport output, I was never able to determine where the compatibility problem might be.  

-D

The problem is often not really linux itself, but more the Grpahics Driver software for Linux …  

I agree.  There seems to be some bad interaction between Linux (or, more specifically, Xorg or the kernel’s i915 driver) and the Club.  As I noted in my reply to support (who did kindly provide the firmware update link), the DisplayPort alternate mode itself works fine, as I can drive the monitor from Linux using either a USB-C-to-DP cable, or several manufacturers’ UCB-C-to-DP adapters followed by a normal DP cable.

When the Club didn’t work, I also tried an identical-looking unit from Plugable, and it had the same problem.  I assumed, though I’m not 100% sure, that they are likely based on the same chipset.

Now that you are three major firmware revs down the road, I’ll try the new firmware and report back on whether it solves the problem.  We are also several Linux kernels and Xorg drivers down the road, so I’ll keep my fingers crossed.  OTOH, the fact that the OP is having problems with Mac OS means that I’m still holding out the possibility that there could still be some bad interaction that hasn’t been specifically addressed 🙂

-D

Looking forward to your feedback

A few results:

1. Our son just bought a new LG 4K monitor (mine is a 2-year-old Benq), so we tried the Club before doing any firmware updating, and it did work from my laptop running Linux, whereas my Benq monitor still did not work.  So there is clearly some monitor dependency to this.
2. I then updated the Club firmware to the version provided by support and now the Benq monitor also works with the Club, so good news there.  Whatever the sensitivity is in the Benq monitor seems to have gotten fixed in the current firmware.

Since the OP has the current firmware in the Club, it would be interesting to find out if he had any luck with creating a custom resolution (that would have been the next thing I would have tried if the firmware update didn’t work).  If that didn’t work, I would suggest borrowing another monitor and seeing if there is a monitor dependency similar to what we saw here.  If there is, there may not be much he can do about it at the moment, but at least he will know where the problem is.

I have to back-pedal a little on those results.

Unfortunately, while the adapter works better with the new firmware, there are still problems.  This morning, it started up okay (from the “startx” command — I don’t generally use DMs), but X seemed to take an unusually long time to start.  I also noticed that while the monitor responded to the 4K/60Hz mode within X, it didn’t respond to the 4K console mode before starting X (it works fine using the monitors DP input).

Then, I tried unplugging it and plugging it back in, and this time, there was no 4K mode recognized at all, only 2560×1440.  Several more unplug-plug cycles resulted in the same thing.  Even quitting X back to the console and re-starting X did not work.

So it does occasionally work now, but not reliably.  I’m not sure what’s going on.  It does seem monitor-dependent, so maybe there are some problems with monitor start-up time or start-up sequence when the monitor detects a signal, and somehow either the DDC or the EDID transfer is occasionally corrupted or not happening properly.  The problem *could* be strictly a monitor problem, and not the fault of the adapter, but I don’t have a PC with a native HDMI 2.0 output, so I have no way of seeing if the problem is present without the adapter.

Probably the next step is to try forcing a custom mode.  It’s more complicated in Linux (Xorg) than in Mac-OS and it’s been years since I’ve done that so I’ll need to look it up and figure it out, so i might not get to it instantly.

Hello Drosky,

Different Screens send the EDID info in different manners. So it is not so much “Monitor dependent” but more “EDID dependent” is the source system can recognize incoming EDID via the adapter of the Screen. If not, then the source system will choose a resolution itself, which is what you don’t want …

Sometimes an update of the firmware of the Screen can help, often crating a custom resolution can help (that normally overwrites what the system would automatically do).

Yeah, I did check for firmware updates for this monitor but there weren’t any.  Since it seems to work reliably under Windows 10, I’m guessing that Windows somehow does a better job of getting the EDID data reliably.  Maybe it waits longer or something, or retries if it gets data that seems corrupt.  There were one or two times where it started working in Linux after the machine had been running for several minutes, so maybe something caused Xorg to re-read the EDID and it then read correctly.  Since it does work sometimes, I suspect it might be a timing problem or something similar, and Windows is better at avoiding it.

When I get a chance, I’ll try a custom mode.  Since it does work sometimes, I should be able to get the correct mode information from xrandr.

ok thanks for the feedback