I’ve added today a second monitor, an HP v185ws, to my HP EliteDesk 800 G3 DM 35W. My primary monitor is an Eizo Flexscan EV2730Q.
The issue I’m facing is that the HP v185ws consistently displays a “No VGA Signal” message when I’m running Ubuntu Budgie 24.04.2 LTS. However, when I switch to Windows 10 on the same machine, both monitors work perfectly fine, with the HP v185ws receiving a signal as expected. This suggests the hardware itself (graphics card, cables, and monitors) is functional.
Given that it works flawlessly in Windows 10, I suspect this is a driver or configuration issue within Ubuntu Budgie.
Here’s what I’ve tried/my current setup:
Computer: HP EliteDesk 800 G3 DM 35W (has only displayports)
Primary Monitor: Eizo Flexscan EV2730Q (connected via Displayport cable)
Secondary Monitor: HP v185ws (connected via Displayport to VGA cable)
Observations: The “No VGA Signal” message persists on the HP v185ws in Ubuntu Budgie.
** xrandr clearly shows DP-2 connected 1366x768+0+473, indicating that Ubuntu Budgie’s display server detects the output and is attempting to send the correct signal (native resolution of the HP v185ws).
** I have noticed that when I move my mouse from my Eizo display to where the HP monitor should be, the mouse cursor actually moves onto the “HP monitor’s” area! This only happens at the precise border where the displays are virtually positioned next to each other according to xrandr. From other parts of the Eizo’s edge, the mouse won’t pass through.
** pics
What maybe happening is that the display frequency you are connecting with on the current setup is too high for the secondary monitor. My understanding (could be wrong here) X based graphics doesnt allow you to have per monitor frequencies.
Sorry about my reaction, I just misunderstood your post. But lets move on.
Key Discoveries
“Safe Graphics Mode” Works (Standalone): When I booted Ubuntu Budgie (or other Ubuntu-based distros) in “safe graphics mode” with only the HP monitor connected, it displays correctly. This confirms the basic drivers and hardware detection are functional, and the monitor can receive a signal. This means the problem isn’t fundamental hardware incompatibility or a completely dead port.
HP Monitor Disconnects When Eizo is Added: The crucial finding is that the HP monitor loses its signal the moment the Eizo monitor is also connected. This happens even though xrandr indicates the HP monitor (via DP-2) is still connected and trying to output a signal.
Consistent Across Ubuntu, Zorin OS: The issue persists across Ubuntu Budgie, standard Ubuntu, and Zorin OS. This strongly suggests the problem isn’t with the desktop environment (Budgie) but is deeper within the Linux kernel and the Intel i915 graphics driver, as these components are shared across these distributions.
What This Implies
This behavior points to a specific bug or resource management issue within the Intel i915 driver when handling two simultaneous display outputs on your HP EliteDesk 800 G3 DM 35W, especially when one involves a DisplayPort-to-VGA adapter. It’s likely a conflict in how the driver allocates resources or initializes the output when both a direct DisplayPort (Eizo) and an adapted DisplayPort (HP v185ws) are active.
Next Steps: Try a Different Distribution Branch
Given that the problem is consistent across Ubuntu-based distributions, the most promising next step is to try a Linux distribution from a different branch, such as a Red Hat-based (e.g., Fedora) or Arch-based (e.g., Manjaro, Arch Linux) distribution.
Why this might help:
Different Kernel Versions: These distributions often use different, potentially newer (or sometimes older but more stable for specific hardware) kernel versions. A different kernel might contain bug fixes or changes that resolve this specific issue with the i915 driver or multi-monitor handling.
Varying Driver Packaging: While the core i915 driver is part of the kernel, other graphics-related packages (like Mesa) and their integration might differ, potentially affecting display output.
How to Test:
Always test first from a Live USB to see if the issue is resolved before committing to an installation.
Look for distributions that are known to ship with very recent kernel versions, as newer kernels often have better hardware support and bug fixes. Fedora is a good candidate for this.
This is a challenging issue, but your detailed observations significantly narrow down the potential causes to the lower levels of the graphics stack.
(English is not my native tongue, so I use Gemini to summarize.)
I’m not competent to provide a technical explanation, but I would give you the same advice as AI and recommend trying distributions other than Ubuntu or Debian-based ones and other kernel versions.
But, since Zorin is based on Ubuntu 22.04 with kernel 6.0.8, the idea that an older kernel version would solve the problem can more or less be eliminated.
However, if you wish, you could try the opposite approach with UB 25.04, which runs with kernel 6.14.
So I’d be more inclined to go for a rolling distribution like Manjaro, which natively includes a management tool that makes it easy to switch kernels and experiment with the latest versions (6.15 or 6.16).
A more radical option would be Solus, which lets you try out both an originally built distribution and 6.14 kernel — and always with the Budgie desktop if you are so inclined.
In short, for want of anything better, I’ll keep on trying, as I’m basically an empiricist.
I got back to Ubuntu Budgie and tried another approach: reading logs. I found this:
2025-07-09T03:18:57.196379+03:00 tasema fwupd[17243]: 00:18:57.196 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:02.0/drm/card1/card1-DP-3/drm_dp_aux2: failed to setup: failed to read device firmware header: checksum mismatch in device response header (header specified: 0x0, actual: 0xAB)
(I tried also plugging cable to another port, so that’s why previously mentioned DP-2 is now DP-3.)
This error shows that fwupd (the firmware updater) failed to communicate with a device on DP-3 (which is likely either my DP-to-VGA adapter or the monitor through it). Specifically, it’s a checksum mismatch when trying to read the device’s firmware header via the DisplayPort auxiliary channel (drm_dp_aux2).
What this tells us (and reinforces my previous points):
This is a low-level communication failure specific to a DisplayPort output from my Intel graphics card (pci0000:00:02.0).
The DisplayPort auxiliary channel is crucial for things like EDID detection and establishing a stable video link. If this communication fails, it would explain why the monitor says “No Signal,” even if xrandrthinks the port is active.
Since the entire setup works perfectly in Windows 10, this strongly suggests that Linux’s i915 driver or fwupd’s interaction with this specific DP-to-VGA adapter is problematic, leading to this checksum error. It implies the adapter’s firmware is either not playing well with Linux’s communication protocols, or there’s a bug in the Linux side.
My question now narrows to:
Are there known issues with i915 (Intel graphics driver) or fwupd causing “checksum mismatch” errors on DisplayPort auxiliary channels, especially with DP-to-VGA adapters?
Are there any kernel parameters or modprobe options for i915 that can change how it interacts with DisplayPort devices, potentially bypassing or mitigating this communication error?
Could this error explain why the “safe graphics mode” works (perhaps it uses a more basic communication that avoids this fwupd/aux channel check) and why adding the Eizo monitor causes the HP monitor to drop out (potentially stressing the aux channel communication or revealing a bug when multiple DP outputs are active)?
Thanks for any insights into this specific checksum mismatch error!
In all these explanations and other technical considerations, you were slow to mention the fact that you were using an adapter and I hadn’t noticed.
A quick Google search shows that the problem is well known and doesn’t date back to the latest version of Ubuntu or this or that kernel.
There are even topics marked as “Solved” on French forums, sometimes by somewhat unthinkable bidouilles.
So I advise you to look around and try without getting discouraged… It would be the end of the world if you didn’t find something — by the way, have you tried with another adapter model?
And if you don’t find anything, to have the wisdom to give up and stick with Windows: these computers were originally designed for it, and you can’t blame Linux for not being able to adapt to all possible configurations and hardware without a hitch.
Would you care to share pointers to this “well known” problem?
Windows is not an option, I am a Linux user, I have been that kind for some 35 years. Yes, I have used the very first Torvalds innovations. I just kept the windows partition for safety reasons which came handy to recover from havoc caused by Solus. I am not blaming anything, I am just telling my observations.
By the way:
That pretty much states that there must be an adapter.
But if there is not so much trouble, could you please share those pointers?
Your investigation has basically found an incompatibility with your adapter. This can only be fixed via a code change, probably via the linux firmware project.
If you are knowledgeable then you could dig in and submit a fix on that project.
Alternatively, best purchase a different adapter and try again.
Or maybe I should buy another monitor. Or sell this monitor that is not working. Eizo alone is proved stable in my Budgie use. But those are so obvious solutions that I do not seek that kind of support although I have been challenged here from my wits. Where to start with the linux firmware project would been valuable information. I know coding, first time I wrote programs with on hpux in year 1987. I have been writing code for linux in 90’s, hardware stuff, video cards cpus et al. So no need for support there either.
Sorry, @kepsulagoprojekt, just a few obvious key words. I haven’t had time this morning to go through the feedback carefully, but it looks like there’s some testing to be done.
