Hello everyone, I’ve got an extremely annoying and random issue that doesn’t seem to be…logical. I’m going through the process of applying 10.06.110 to our UD3 devices, most of these devices are set up with dual monitors, some are LX50ac devices and others are LX51ac devices. Additional information to know is that I have a nightly job run to shut down the terminals and another to start them up in the morning. We also utilize a DVI cable for one of the monitors, and a DisplayPort to HDMI cable for the other monitor. There is a profile that is pushed to all dual monitor users that sets the DisplayPort cable as the left (1) monitor, this is for sound and consistency purposes.
After applying the 10.06.110 firmware some of my users with dual monitors were suddenly finding their main screen on the right instead of the left. Pushing profiles, rebooting, rolling back firmware, creating completely new profiles with minor adjustments would not change this. This doesn’t happen to all of my users, in fact some of my users are fine for a week and then suddenly the monitors will flip. In some cases I’ve had to reconfigure an entirely new terminal at my desk, swap that with their old terminal, and everything might be fine for a day or less before it suddenly flips again.
The real icing on the cake was yesterday when I replaced one of the iGels, everything was fine, and then suddenly that afternoon the monitors had flipped while the user was idle. I attempted everything under the sun to try and get everything set right, but it wouldn’t budge. This morning I went to look at the device and wouldn’t you know it? The dang monitors were the right away suddenly! And yes, during all of my troubleshooting I did reboot the device throughout each attempt.
Now I’ve run into dual monitor issues before, yet in previous situations I was always able to roll back the firmware, reapply the profiles, reboot and everything would be fine. Yet now that only sometimes works. I hate issues that aren’t consistent, I can’t recreate this issue at my desk no matter how many terminals I configure and set up. Normally I’d start looking at any user behaviour if it were only a user or two, but this is spreading at random across all departments.
At my wits end I downloaded the 10.06.130 firmware to try that at my desk to see how everything went, and this time at my desk I got a pop up regarding my monitor identification. What I found extremely odd was that my DVI cable was being classified as HDMI by iGel. If this is the possible issue, then that could possibly explain this strange behaviour. Has anyone run into something like this? I’m not receiving consistent feedback from my users so I’m possibly not getting the full picture, needless to say I’m going a bit crazy trying to figure out this oddly sporadic issue. I appreciate everyone’s time and assistance with this, I am open to any and all ideas as I’ve just been made aware that this issue is continuing to spread in areas that we had thought were fine. Thank you!
Hi, this topic isn‘t easy to answer… I had a consistent setup by using the display switcher (locally) instead of the profile one, and there user can setup their setup as they wish… but @member @member @member @member and a few others reported different display settings issues when upgrading firmware. I would be happy to have you opening a ticket, because I believe we need a reliable communication about what users/customers/admins can expect. Makes sense?
Hi and thank you for your response! Would I be opening a UDC technical support ticket? I’m never sure what option to take as the categories never really seem to fit quite right.
Happy to hear other people are having the issue i have! @member I have exaclty the same issue you have.
using display switch locally instead of using profile via UMS is not appliable in many cases due to lack of control by admin.
that’s my exact issue, because we use StoreFront our users don’t have any access to display settings. It’s slightly maddening that I can’t control this through the profile.
Well, I decided to create a profile with DisplayPort as monitor 1 and HDMI as monitor 2 (monitor 2 is actually a DVI cable to DVI cable). And so far that’s fixed the issue for the users I’ve been able to test with. I have no clue.
yes, UDC fits good!
ok, got your point!
As an update, I’ve switched all updated devices to use DisplayPort on monitor one, and HDMI on monitor two (even though the monitor two cable is a DVI cable). After the overnight shut down and morning start up it appears all of the devices are still correct. I’m still wary about this, but that’s probably because all projects in general have gone poorly since June. Also, my ticket had a response that was supposed to contain a KB article, however there wasn’t one linked. Once i get it I’ll share it in case it helps anyone else. 🙂
So, your workaround (HDMI+DP configuration) has a (hidden, though obvious once known) cause:
The DVI port is recognized as HDMI on those devices. This isn’t visible in UMS configuration (maybe on status? I’m unsure about that), but will be obvious when you try to configure on the device itself.
While this is known, changing it at this point would break existing profiles 😕
As for why it sometimes changes at seemingly random times, my best guess is that it’s related to power saving features. Some Displays will pretend to be unplugged when they are turned off for power saving, which is a rather obnoxious source of errors.
The setting: sessions.user_display0.options.disable_hotplug (only available via registry) can remedy some of those issues, but will cause weird behaviours when hotplug is an intended action.
I think the reason this was so perplexing was that I set up every terminal at my desk before sending it out for use. When I tested this firmware I had used a DisplayPort+DVI profile for dual monitors, and nothing behaved oddly. It’s when they went out into production that we experienced this issue. I’d say there was a monitor correlation, however the users who experienced this issue had varying models and brands of monitors. 🤷
If this is a known bug, was this resolved in 10.06.130? Or would the 11 upgrade be necessary? The bummer about not being able to replicate the issue is that I wasn’t prepared, and none of my usual tricks would fix this which caused a delay. I’ll now have to be a lot slower when pushing updates, and I already felt slow about this. 😞
More of a known issue than a bug. This is a Hardware pecularity, and changing it now isn’t backwards compatible.
And yes, testing often doesn’t go into the power saving. AND this doesn’t happen with every monitor (it’s DP specific, and even then not every device). So I’m not surprised it didn’t show up
Oh boy, well…OS 11 is going to be a slow testing process then. My users are pretty exasperated, so I’ll need to give them time before jumping in with anything else new. Thank you
I think its a Problem that the LX doesnt talk/ask often enough the Display connectors. I fight now over a year and 4 Firwares with display switcher and the side issues. 6.120 is actual the best version but some issues always…. Important input is that the probs have UD units. I have collect my experience only with converted HP Elitebooks and so we think most time, that its could be a hardware compatbility Problem…
I realize this is older, but I want to give all the information I can to help anyone who may come across this in the future.
After weeding through all of the users who reported issues, users who didn’t report issues, and users who misreported issues, I finally narrowed things down. Any of our UD3-LX devices with dual ASUS monitors were experiencing the random issues. Our users with BENQ or Dell monitors were fine. (Our users always have matching monitors, I’m not sure how this would behave in a BENQ+ASUS dual setup).
Ultimately, after many iGel setting tweaks, monitor setting adjustments, and frustration, I had to roll back the devices with ASUS monitors to 10.05.830. As far as I can tell, this is the furthest point I can go with OS 10 on these devices.
My advice that I’ll personally be following when it comes to dual monitor tests, is to run a test with ALL your monitor brands. Hopefully this helps keep some others out there sane. 🙂
I wrote two sets of documentation based on monitor type for our users. For those who have older monitors with D.V.I. ports, the thin client defaults to using the D.V.I. monitor on the left and the DisplayPort monitor on the right. For those who have newer monitors with H.D.M.I. ports instead of D.V.I. ports, they default to having the DisplayPort monitor on the left and the D.V.I. /H.D.M.I. monitor on the right. That’s fine, but we’re also finding that when updating from 10.05.500 to 10.06.120, it reverts their monitor settings to being mirrored, and doesn’t always keep the intended monitor configuration (even after reconfiguration because of the update). I’m still gathering information to make sure that we’re understanding this new problem correctly, but that is what it seems like. I’m thinking of making an xrandr script based on the monitor/connection type, since the profile might not be granular enough, but maybe there is a better way.
Continue reading and comment on the thread ‘Monitors were suddenly finding their main screen on the right instead of the left on IGEL OS’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above messasge thread?Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.
Submit a question, or Join Today!
Popular Message Threads
- USB webcams in combination with RDP on IGEL OS?
- IGEL OS on Raspberry Pi?
- After upgrading to IGEL OS 11.04.200.01 my Citrix Storefront configuration does not work anymore – Error adding store: AM_ERROR_AUTH_NETWORK_ERROR
- IGEL UMS Universal Update Error: “could not resolve host name”
- Citrix session crashes with black screen, any advice and how do I find logging?
- What is required for Zoom VDI/Zoom Media Plugin for Citrix on IGEL OS?
- Lanching a published desktop via Citrix gives me “Error adding store:AM_ERROR_AUTH_NETWORK_ERROR”