rockowitz / ddcutil

Control monitor settings using DDC/CI and USB
http://www.ddcutil.com
GNU General Public License v2.0
904 stars 38 forks source link

LG 29UM69G fails switching input #100

Open jonpas opened 4 years ago

jonpas commented 4 years ago

LG 29UM69G fails at switching monitor inputs. I did not try other capabilities. Performing $ ddcutil --display 2 setvcp 60 0x[0f|11] simply flashes the screen, but nothing changes.

$ ddcutil detect
...
Display 2
   I2C bus:             /dev/i2c-6
   EDID synopsis:
      Mfg id:           GSM
      Model:            LG ULTRAWIDE
      Serial number:    
      Manufacture year: 2019
      EDID version:     1.3
   VCP version:         2.1

There is no Supports DDC: [true|false] in the output.

$ ddcutil environment shows all permissions are correct (read & write).

$ ddcutil --display 2 getvcp 60
VCP code 0x60 (Input Source                  ): Invalid value (sl=0x00)

This shows up correctly as VGA-1 (sl=0x01) for display 1 (secondary monitor).

ClickMonitorDDC on Windows has the same issue of reporting 0x00 and not being able to switch.

$ ddcutil capabilities --display 2 --verbose
...
Unparsed capabilities string: (prot(monitor)type(lcd)UM69cmds(01 02 03 0C E3 F3)vcp(02 04 05 08 10 12 14(05 08 0B ) 16 18 1A 52 60( 11 0F 10) AC AE B2 B6 C0 C6 C8 C9 D6(01 04) DF 62 8D F4 F5(01 02 03 04) F6(00 01 02) 4D 4E 4F 15(01 06 11 13 14 15 18 19 20 22 23 24 28 29 32 48) F7(00 01 02 03) F8(00 01) F9 E4 E5 E6 E7 E8 E9 EA EB EF FA(00 01) FD(00 01) FE(00 01 02) FF)mccs_ver(2.1)mswhql(1))
...
   Feature: 60 (Input Source)
      Values (unparsed):  11 0F 10
      Values (  parsed):
         0f: DisplayPort-1
         10: DisplayPort-2
         11: HDMI-1

Both monitors are connected to both an integrated GPU (Intel CPU) and dedicated GPU (GTX 1060) in the following way (VFIO setup):

Thank you in advance!

rockowitz commented 4 years ago

Displays vary in how they implement DDC when multiple monitors are attached.  Feature code x60 is particularly problematic. For some, setvcp works only if issued from the device whose input is selected.  That is, ddcutil or ClickMonitorDDC work only if issued on the currently selected input. For others, setvcp 60 works no matter what the input.

I assume since you mention ClickMonitorDDC that you're running Windows in a VM.  So as a first step, check whether ddcutil setvcp 60 or ClickMonitorDDC work when used on the currently active input.

DisplayPort connections are also problematic.  Can you configure so that DVI or HDMI, not DisplayPort, is used for the 29UM69G?

Finally, LG monitors, particularly Ultrawide monitors, have been seen to depart from the DDC standard.  See the description of "LG Ultrawide" in http://www.ddcutil.com/monitor_notes, which includes the following:

"When responding to a Get VCP Feature request, the monitor never sets the Result Code field of the VCP Feature Reply to Unsupported VCP Code. Instead, it always reports No Error. For unsupported VCP codes, all bytes in the response (MH, ML, SH, SL) are set to x00."

So that's the explanation for the x00 response you're seeing.  ddcutil tries to figure out if a display (pathologically) uses an all 0 response to indicate unsupported, but it's a heuristic test and isn't perfect.  If the answer is yes, that is stated in the monitor description.

The test that is reported by the "Supports DDC" line in the monitor description has been eliminated.  It was a simple test that probed slave address x37 without actually trying to communicate.   That was found to not always be accurate.  Instead, ddcutil simply uses whether DDC protocol communication works.  If it does, you see the "VCP version" line, if not there a message that the display does not support DDC.

Please run command "ddcutil interrogate"  when the input is set to the source of the command, and send the output as an attachment.

Sanford

On 12/14/19 7:55 AM, jonpas wrote:

LG 29UM69G fails at switching monitor inputs. I did not try other capabilities. Performing |$ ddcutil --display setvcp 2 60 0x[0f|11]| simply flashes the screen, but nothing changes.

|$ ddcutil detect ... Display 2 I2C bus: /dev/i2c-6 EDID synopsis: Mfg id: GSM Model: LG ULTRAWIDE Serial number: Manufacture year: 2019 EDID version: 1.3 VCP version: 2.1 |

There is no |Supports DDC: [true|false]| in the output.

|$ ddcutil environment| shows all permissions are correct (read & write).

|$ ddcutil --display 2 getvcp 60 VCP code 0x60 (Input Source ): Invalid value (sl=0x00) |

This shows up correctly as |VGA-1 (sl=0x01)| for display 1 (secondary monitor).

|$ ddcutil capabilities --display 2 --verbose ... Unparsed capabilities string: (prot(monitor)type(lcd)UM69cmds(01 02 03 0C E3 F3)vcp(02 04 05 08 10 12 14(05 08 0B ) 16 18 1A 52 60( 11 0F 10) AC AE B2 B6 C0 C6 C8 C9 D6(01 04) DF 62 8D F4 F5(01 02 03 04) F6(00 01 02) 4D 4E 4F 15(01 06 11 13 14 15 18 19 20 22 23 24 28 29 32 48) F7(00 01 02 03) F8(00 01) F9 E4 E5 E6 E7 E8 E9 EA EB EF FA(00 01) FD(00 01) FE(00 01 02) FF)mccs_ver(2.1)mswhql(1)) ... Feature: 60 (Input Source) Values (unparsed): 11 0F 10 Values ( parsed): 0f: DisplayPort-1 10: DisplayPort-2 11: HDMI-1 |

ClickMonitorDDC on Windows has the same issue of reporting |0x00| and not being able to switch.


Both monitors are connected to both an integrated GPU (Intel CPU) and dedicated GPU (GTX 1060) in the following way (VFIO setup):

  • Display 1 (secondary): o VGA -> iGPU o DVI -> dGPU
  • Display 2 (primary, LG 29UM69G): o HDMI -> iGPU o DisplayPort -> dGPU

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100?email_source=notifications&email_token=ADMGY3QQW2HL3D6TSKIMH2LQYTJUPA5CNFSM4J22O4BKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IAP3SNA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XTANLUXQ4L6YUI32DQYTJUPANCNFSM4J22O4BA.

jonpas commented 4 years ago

I assume since you mention ClickMonitorDDC that you're running Windows in a VM. So as a first step, check whether ddcutil setvcp 60 or ClickMonitorDDC work when used on the currently active input.

Correct, Windows is in a VM, host is Arch Linux. That is why I tried both ddcutil and ClickMonitorDDC, but neither combination worked.

DisplayPort connections are also problematic. Can you configure so that DVI or HDMI, not DisplayPort, is used for the 29UM69G?

Sadly not possible, as 29UM69G only has 1x HDMI, 1x DisplayPort and 1x USB-C Alt. DP.

So that's the explanation the x00 response you're seeing.

Ah, I read that but didn't quite understand it, thanks for the explanation.

Please run command "ddcutil interrogate" when the input is set to the source of the command, and send the output as an attachment.

Here you go, ran $ ddcutil interrogate on Linux host (connected with HDMI to iGPU): ddcutil_interrogate.log

rockowitz commented 4 years ago

On 12/14/19 2:49 PM, jonpas wrote:

I assume since you mention ClickMonitorDDC that you're running Windows
in a VM. So as a first step, check whether ddcutil setvcp 60 or
ClickMonitorDDC work when used on the currently active input.

Correct, Windows is in a VM, host is Arch Linux. That is why I tried both ddcutil and ClickMonitorDDC, but neither combination worked.

Let me put the question more precisely. When the monitor is displaying your Linux system, do getvcp and setvcp work for feature x60? What about feature x10 (brightness)? Conversely, when the monitor is displaying your VM Windows system, can ClickMonitorDDC change the input to Linux?  Can it change any of the more ordinary features such as brightness?

DisplayPort connections are also problematic. Can you configure so
that
DVI or HDMI, not DisplayPort, is used for the 29UM69G?

Sadly not possible, as 29UM69G only has 1x HDMI, 1x DisplayPort and 1x USB-C Alt. DP.

So that's the explanation the x00 response you're seeing.

Ah, I read that but didn't quite understand it, thanks for the explanation.

Please run command "ddcutil interrogate" when the input is set to the
source of the command, and send the output as an attachment.

Here you go, ran |$ ddcutil --display 2 interrogate| on Linux host (connected with DisplayPort to dGPU): ddcutil_interrogate.log https://github.com/rockowitz/ddcutil/files/3964274/ddcutil_interrogate.log

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100?email_source=notifications&email_token=ADMGY3WJAQLIWEWM4K542S3QYU2FVA5CNFSM4J22O4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4J5TQ#issuecomment-565747406, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QFEZFGOFFKCDQSUE3QYU2FVANCNFSM4J22O4BA.

jonpas commented 4 years ago

Monitor displaying Linux (HDMI to iGPU - ddcutil):

Monitor displaying VM Windows (DisplayPort to dGPU - ClickMonitorDDC):

Brightness, contrast, volume etc. can also be set over non-active input and it works perfectly. Input however does nothing.

rockowitz commented 4 years ago

Well, that pretty much nails it.  It's the monitor's implementation of feature x60.

To further confirm, you might try using Windows program softMCCS by enTech. (https://www.entechtaiwan.com/lib/softmccs.shtm). enTech is a maker of DDC chips for monitors, and softMCCS is designed to exercise implementations.

So that I can better understand/document this monitor, I'd appreciate it if you would run the following commands (assuming your physical configuration is unchanged) and send me the output.   Thanks.

  ddcutil getvcp 10 --bus 6 --trcfunc invoke_i2c_reader --trcfunc ddc_write_read --verbose   ddcutil getvcp 11 --bus 6 --trcfunc invoke_i2c_reader --trcfunc ddc_write_read --verbose

Sanford

On 12/15/19 6:53 AM, jonpas wrote:

Monitor displaying Linux (HDMI to iGPU - |ddcutil|):

  • |getvcp 60| always returns |0| (LG Ultra-Wide issue)
  • |setvcp 60 0x<>| just blinks the monitor, nothing changes (tried all 3 given options)
  • |getvcp 10| correctly returns current brightness
  • |setvcp 10 [50|100|...]| correctly sets brightness (as well as contrast, volume etc.)

Monitor displaying VM Windows (DisplayPort to dGPU - ClickMonitorDDC):

  • Input always shows |0| (LG Ultra-Wide issue)
  • Changing input just blinks the monitor, nothing changes
  • Current brightness is correctly shown
  • Brightness can be set (as well as contrast, volume etc.)

Brightness, contrast, volume etc. can also be set over non-active input and it works perfectly. Input however does nothing.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100?email_source=notifications&email_token=ADMGY3S3J6B7KYPGP4IBCQ3QYYLEXA5CNFSM4J22O4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG4XM7Y#issuecomment-565802623, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QMEF2RDRGZUE5ZZI3QYYLEXANCNFSM4J22O4BA.

jonpas commented 4 years ago

softMCCS gets all the correct codes but switching also fails with the same blank and return. Everything works correctly with my secondary (old Samsung SyncMaster) screen.

ddcutil_getvcp10_trcfunc.log ddcutil_getvcp11_trcfunc.log

rockowitz commented 4 years ago

Thanks for the logs.  I stand corrected.  From the logs I see that the monitor is properly not setting the supported feature bit for feature x00 (by definition not a value feature) and feature x11 (which I've never seen implemented).  So it looks like the SL byte value x00 returned for feature x60 is just a special case reflecting the bad implementation of feature x60.

Sanford

On 12/16/19 9:55 AM, jonpas wrote:

softMCCS gets all the correct codes but switching also fails with the same blank and return.

ddcutil_getvcp10_trcfunc.log https://github.com/rockowitz/ddcutil/files/3968549/ddcutil_getvcp10_trcfunc.log ddcutil_getvcp11_trcfunc.log https://github.com/rockowitz/ddcutil/files/3968550/ddcutil_getvcp11_trcfunc.log

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100?email_source=notifications&email_token=ADMGY3SEC3MFWXWW3X6Z7BLQY6JFTA5CNFSM4J22O4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG664TI#issuecomment-566095437, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3THNSAYGTFQBTKGRNDQY6JFTANCNFSM4J22O4BA.

jonpas commented 4 years ago

I assume there is no workaround to make feature x60 work properly?

And no problem!

rockowitz commented 4 years ago

There's nothing in my toolbox to solve the problem. Since it appears in ClickMonitorDDC and softMCCS as well as ddcutil it's clearly a hardware problem in the monitor. All I can suggest is contacting LG tech support. If they get back to you please post their response here.

Sanford

On 12/16/2019 12:04 PM, jonpas wrote:

I assume there is no workaround to make feature x60 work properly?

And no problem!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100?email_source=notifications&email_token=ADMGY3QWVYXYDG3BQWJHLCLQY6YLBA5CNFSM4J22O4BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG7MOKQ#issuecomment-566150954, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SKVZAH7FQYPQKIU3LQY6YLBANCNFSM4J22O4BA.

jonpas commented 4 years ago

Thank you for your help. I will post here if I get any more information.

SkyLeite commented 4 years ago

I have this exact same issue with a 6 months old monitor. Seems unlikely that it would be hardware related, but I'm just speculating.

davemap commented 4 years ago

I have the same issue and would be great if we could find a fix. @jonpas, have you heard anything from LG?

jonpas commented 4 years ago

Negative, it was presumably passed to their technical department, but there has been no other reply so far.

Gimzie commented 4 years ago

It seems my LG 34WK500-P ultrawide monitor has the same issue. Changing control 0x60 to any value flashes the screen and returns to the current input. Interestingly, executing the command from my only connected device (my Manjaro PC) while being on the other (unused) HDMI input causes the OSD to pop up directly on the input list.

rockowitz commented 4 years ago

I'm not clear how to interpret "executing the command from my only connected device (my Manjaro PC) while being on the other (unused) HDMI input".  What computers (or virtual machines with a dedicated video card using passthru) are connected to which monitor inputs?

On 7/8/20 1:05 PM, Gimzie wrote:

It seems my LG 34WK500-P ultrawide monitor has the same issue. Changing control 0x60 to any value flashes the screen and returns to the current input. Interestingly, executing the command from my only connected device (my Manjaro PC) while being on the other (unused) HDMI input causes the OSD to pop up directly on the input list.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-655642786, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SBSVJCKTXQREHHYVDR2SROBANCNFSM4J22O4BA.

Gimzie commented 3 years ago

Sorry for the late reply (I sort of forgot about this thread) but I have my PC connected to HDMI 2 (running Manjaro Linux on an Intel UHD Graphics 630), and I have all of my GPU passthrough VMs set to use HDMI 1 (with my Nvidia Geforce GTX 1060 3GB card).

rockowitz commented 3 years ago

I'm afraid I have nothing to add here. Seems like another LG idiosyncratic DDC implementation.

yeahman45 commented 3 years ago

I'm afraid I have nothing to add here. Seems like another LG idiosyncratic DDC implementation.

is this something that can be corrected in software/firmware (if that is the case, we can try asking LG technical support) or it is in hardware?

davemap commented 3 years ago

I'm afraid I have nothing to add here. Seems like another LG idiosyncratic DDC implementation.

is this something that can be corrected in software/firmware (if that is the case, we can try asking LG technical support) or it is in hardware?

Personally I'm not too sure. I think a couple of us have opened cases with LG support but I'm pretty sure my case has got lost because it probably isn't work their time.or effort to investigate. However, if enough people raise the question, we may see some results

yeahman45 commented 3 years ago

ok it is worth trying.

For my monitor lg 29um68-p, switching to hdmi 1 works but all other inputs (hdmi 2 and displayport) do not work. :(

marcosscriven commented 3 years ago

Came here looking for help with this on an LG 38WN95C - same thing, changing control 60 does nothing, whereas other things like brightness works. Was hoping for a workaround, but clearly there isn't one at the moment.

marcosscriven commented 3 years ago

@rockowitz - can something like ddcutil watch help here? I tried it and this is the only output I get, over and over:

sudo ddcutil watch      
Watching for VCP feature changes on display [i2c: fd=3, busno=7]
Type ^C to exit...
(new_control_values_exist      ) New control values exist. x02 value: 0x02
(reset_vcp_x02                 ) reset feature x02 (new control value) successful

Every time the reset line is logged, the OSD disappears. I was trying to change the input while running watch.

TaiSHiNet commented 3 years ago

@marcosscriven strangely, that one lists DDC/CI in the specs (unlike others, including mine)

rockowitz commented 3 years ago

I do have one further thought on this problem, though it's just a hunch. Picture By Picture mode complicates the logic of switching inputs.
Feature x60 was not designed with this capability in mind. Presumably X60 applies to the main (left) screen. The problems you're having may reflect how x60 was implemented given this increased complexity.

On 09/09/2020 01:36 PM, Marcos Scriven wrote:

Came here looking for help with this on an LG 38WN95C - same thing, changing control 60 does nothing, whereas other things like brightness works. Was hoping for a workaround, but clearly there isn't one at the moment.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-689712611, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3V2HWXG6QCNYFRND6DSE64IHANCNFSM4J22O4BA.

marcosscriven commented 3 years ago

From an OSD menu perspective, PBP is a separate mode. In regular mode, one can choose an input from the top level. When in PBP mode, the menu changes, and then one has options for what goes on which side. All that said - does this means potentially there’s still something that can be sent over I2C would do it, albeit nonstandard? And could this be determined empirically in a safe manner? Or is the only safe option (I.e not bricking your monitor) to beg LG to help somehow (which we all know means somehow getting past requests like “reinstall Windows” etc.)?

marcosscriven commented 3 years ago

Another thought - I see running ddcutil capabilities shows a number of "manufacturer specific features". Could any of these potentially be used to change inputs? I can't find any explanation of this.

   Feature: F4 (manufacturer specific feature)
   Feature: F5 (manufacturer specific feature)
      Values: 01 02 03 04 (interpretation unavailable)
   Feature: F6 (manufacturer specific feature)
      Values: 00 01 02 (interpretation unavailable)
   Feature: 4D (unrecognized feature)
   Feature: 4E (unrecognized feature)
   Feature: 4F (unrecognized feature)
   Feature: 15 (unrecognized feature)
      Values: 01 06 11 13 14 15 18 19 20 22 23 24 28 29 32 48 (interpretation unavailable)
   Feature: F7 (manufacturer specific feature)
      Values: 00 01 02 03 (interpretation unavailable)
   Feature: F8 (manufacturer specific feature)
      Values: 00 01 (interpretation unavailable)
   Feature: F9 (manufacturer specific feature)
   Feature: EF (manufacturer specific feature)
   Feature: FA (manufacturer specific feature)
      Values: 00 01 (interpretation unavailable)
   Feature: FD (manufacturer specific feature)
      Values: 00 01 (interpretation unavailable)
   Feature: FE (manufacturer specific feature)
      Values: 00 01 02 (interpretation unavailable)
   Feature: FF (manufacturer specific feature)

Just looking at the value of the first one, for example:

sudo ddcutil getvcp F4  
VCP code 0xf4 (Manufacturer Specific         ): mh=0xff, ml=0xff, sh=0x00, sl=0x06

I have no idea what this means? Or how dangerous it would be to randomly start setting values.

marcosscriven commented 3 years ago

Further to the above, I noticed one can get all manufacturer code values:

sudo ddcutil getvcp MANUFACTURER 
VCP code 0xe2 (Manufacturer Specific         ): mh=0xff, ml=0xff, sh=0x00, sl=0x01
VCP code 0xe4 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x00
VCP code 0xe5 (Manufacturer Specific         ): mh=0x00, ml=0xb3, sh=0x00, sl=0x00
VCP code 0xe7 (Manufacturer Specific         ): mh=0xff, ml=0xff, sh=0x00, sl=0x00
VCP code 0xe8 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x00
VCP code 0xe9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x02
VCP code 0xea (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x00
VCP code 0xeb (Manufacturer Specific         ): mh=0x00, ml=0x01, sh=0x00, sl=0x00
VCP code 0xef (Manufacturer Specific         ): mh=0xff, ml=0xff, sh=0x5a, sl=0x60
VCP code 0xf4 (Manufacturer Specific         ): mh=0xff, ml=0xff, sh=0x00, sl=0x06
VCP code 0xf5 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x02
VCP code 0xf6 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x00
VCP code 0xf7 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x02
VCP code 0xf8 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x01
VCP code 0xf9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x32
VCP code 0xfa (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0xff
VCP code 0xfb (Manufacturer Specific         ): mh=0x00, ml=0x0f, sh=0x00, sl=0x02
VCP code 0xfe (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x03

I noticed that 0xf9 changed from 0x32 to 0x46 when I swapped which side of PBP it was.

I thought therefore setting it by ddcutil might change it back, but I get a validation error:

sudo ddcutil setvcp f9 46   
Verification failed for feature f9

Sorry to bug @rockowitz - but do you have any guidance here please?

marcosscriven commented 3 years ago

Sorry for the stream - one other thing I tried is sudo ddcutil getvcp SCAN before and after swapping between HDMI 1 and HDMI 2 inputs. The only thing I see changing is the sh part of 0xAF:

HDMI 1

VCP code 0xaf (Unknown feature               ): mh=0x00, ml=0xff, sh=0x00, sl=0x00

HDMI 2

VCP code 0xaf (Unknown feature               ): mh=0x00, ml=0xff, sh=0xff, sl=0x00

So I tried setting this, to see if it would switch between HDMI 1 & 2.

However, it doesn't work directly with getvcp or setsvcp:

sudo ddcutil getvcp 0xaf
Unrecognized VCP feature code: 0xaf

sudo ddcutil setvcp 0xaf 0x0000  
Unrecognized VCP feature code: 0xaf

Is there any way @rockowitz to set an Unknown feature that can be read with sudo ddcutil getvcp SCAN?

marcosscriven commented 3 years ago

One more thing - I ran the scan again and saw more things change between HDMI 1 and 2:

< VCP code 0x0c (Color temperature request     ): 3000 + 35 * (feature 0B color temp increment) degree(s) Kelvin
---
> VCP code 0x0c (Color temperature request     ): 3000 + 45 * (feature 0B color temp increment) degree(s) Kelvin
5c5
< VCP code 0x10 (Brightness                    ): current value =    85, max value =   100
---
> VCP code 0x10 (Brightness                    ): current value =   100, max value =   100
8c8
< VCP code 0x15 (Unknown feature               ): mh=0x00, ml=0xff, sh=0x00, sl=0x0b
---
> VCP code 0x15 (Unknown feature               ): mh=0x00, ml=0xff, sh=0x00, sl=0x1e
23c23
< VCP code 0x62 (Audio speaker volume          ): current value =    34, max value =   100
---
> VCP code 0x62 (Audio speaker volume          ): current value =    37, max value =   100
31c31
< VCP code 0x87 (Sharpness                     ): current value =    50, max value =   100
---
> VCP code 0x87 (Sharpness                     ): current value =    70, max value =   100
35c35
< VCP code 0xaf (Unknown feature               ): mh=0x00, ml=0xff, sh=0x01, sl=0x00
---
> VCP code 0xaf (Unknown feature               ): mh=0x00, ml=0xff, sh=0x02, sl=0x00
38c38
< VCP code 0xc1 (Unknown feature               ): mh=0x01, ml=0x2c, sh=0x00, sl=0x55
---
> VCP code 0xc1 (Unknown feature               ): mh=0x01, ml=0x2c, sh=0x00, sl=0x64
62c62
< VCP code 0xf9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x32
---
> VCP code 0xf9 (Manufacturer Specific         ): mh=0x00, ml=0xff, sh=0x00, sl=0x46
rockowitz commented 3 years ago

You could try executing the watch loop using individual ddcutil commands. That MAY allow you to learn something about what features are changed before the OSD disappears. Basically, here's pseudo-code for what watch does:

while (true): sleep(.5) # prevent the loop from consuming all the cpu cycles x02_val = getvcp x02 # this is pseudo-code, the getvcp command reports the value, but does not return it if x02_val == x02: # one or more new control values have changed x52_val = getvcp x52 while (x52_val != 0x00): changed_value = getvcp x52_val report the changed feature value setval x02 x01 # reset feature x02

For VCP 2.2, whether the OSD is enabled and sends button events is controlled by feature xCA. This is a complex non-continuous feature, introduced in VCP 3.0/2.2. If you're able to read feature codes from x52, you don't need to worry about it.

Assuming your VCP version is 2.2, see sections of the VESA Monitor Control Command Set Standard, V 2.2a https://milek7.pl/ddcbacklight/mccs.pdf.

  1. Co-existence of Local and Remote Adjustment Options 8.3.2: OSD/Button Event control (xCA) 8.5: Miscellaneous Functions VCP codes (x02, x52) Appendix B.2: Keeping Local and Remote Operations in Synchronization

On 09/09/2020 01:54 PM, Marcos Scriven wrote:

@rockowitz https://github.com/rockowitz - can something like |ddcutil watch| help here? I tried it and this is the only output I get, over and over:

|sudo ddcutil watch Watching for VCP feature changes on display [i2c: fd=3, busno=7] Type ^C to exit... (new_control_values_exist ) New control values exist. x02 value: 0x02 (reset_vcp_x02 ) reset feature x02 (new control value) successful |

Every time the reset line is logged, the OSD disappears. I was trying to change the input while running watch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-689721584, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QGUTBARAIYIFXNRGLSE66MJANCNFSM4J22O4BA.

rockowitz commented 3 years ago

Perusing the monitor documentation, LG does not seem to have a Windows program for controlling the extended settings. It may be that some features are controllable only within the OSD.

If I2C were used, this could be implemented one in several ways:

Only the first way is easy to test. The others would require sniffing the I2C bus, either physically or by enabling some sort of tracing within Windows.

Finally, if it were my monitor I wouldn't worry about bricking it by testing. I've never done it. (Of course, you're is not exactly cheap.) You might need to reset the monitor to factory defaults using feature x05, or turn the monitor off and back on. The only things I regard as dangerous are updating firmware or poking around in a service menu.

On 09/09/2020 03:28 PM, Marcos Scriven wrote:

From an OSD menu perspective, PBP is a separate mode. In regular mode, one can choose an input from the top level. When in PBP mode, the menu changes, and then one has options for what goes on which side. All that said - does this means potentially there’s still something that can be sent over I2C would do it, albeit nonstandard? And could this be determine empirically in a safe manner? Or is the only safe option (I.e not bricking your monitor) to beg LG to help somehow (which we all know means somehow getting past the request to “reinstall Windows” etc.)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-689769617, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3SM3JUCVFURDZPTZU3SE7JOHANCNFSM4J22O4BA.

rockowitz commented 3 years ago

A manufacturer specific feature that changes the monitor inputs would be a simple non-continuous feature. That is, a feature where the capabilities string has a list of possible values. Feature x15 is also interesting in your case -it is not defined in the MCCS standard.

On 09/10/2020 12:11 PM, Marcos Scriven wrote:

Another thought - I see running |ddcutil capabilities| shows a number of "manufacturer specific features". Could any of these potentially be used to change inputs? I can't find any explanation of this.

|Feature: F4 (manufacturer specific feature) Feature: F5 (manufacturer specific feature) Values: 01 02 03 04 (interpretation unavailable) Feature: F6 (manufacturer specific feature) Values: 00 01 02 (interpretation unavailable) Feature: 4D (unrecognized feature) Feature: 4E (unrecognized feature) Feature: 4F (unrecognized feature) Feature: 15 (unrecognized feature) Values: 01 06 11 13 14 15 18 19 20 22 23 24 28 29 32 48 (interpretation unavailable) Feature: F7 (manufacturer specific feature) Values: 00 01 02 03 (interpretation unavailable) Feature: F8 (manufacturer specific feature) Values: 00 01 (interpretation unavailable) Feature: F9 (manufacturer specific feature) Feature: EF (manufacturer specific feature) Feature: FA (manufacturer specific feature) Values: 00 01 (interpretation unavailable) Feature: FD (manufacturer specific feature) Values: 00 01 (interpretation unavailable) Feature: FE (manufacturer specific feature) Values: 00 01 02 (interpretation unavailable) Feature: FF (manufacturer specific feature) |

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-690420632, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XMH5DNM45JA6AW3ITSFD3DFANCNFSM4J22O4BA.

rockowitz commented 3 years ago

The feature is likely read-only.

On 09/10/2020 12:26 PM, Marcos Scriven wrote:

Further to the above, I noticed one can get all manufacturer code values:

|sudo ddcutil getvcp MANUFACTURER VCP code 0xe2 (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x01 VCP code 0xe4 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 VCP code 0xe5 (Manufacturer Specific ): mh=0x00, ml=0xb3, sh=0x00, sl=0x00 VCP code 0xe7 (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x00 VCP code 0xe8 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 VCP code 0xe9 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x02 VCP code 0xea (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 VCP code 0xeb (Manufacturer Specific ): mh=0x00, ml=0x01, sh=0x00, sl=0x00 VCP code 0xef (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x5a, sl=0x60 VCP code 0xf4 (Manufacturer Specific ): mh=0xff, ml=0xff, sh=0x00, sl=0x06 VCP code 0xf5 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x02 VCP code 0xf6 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 VCP code 0xf7 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x02 VCP code 0xf8 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x01 VCP code 0xf9 (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x32 VCP code 0xfa (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0xff VCP code 0xfb (Manufacturer Specific ): mh=0x00, ml=0x0f, sh=0x00, sl=0x02 VCP code 0xfe (Manufacturer Specific ): mh=0x00, ml=0xff, sh=0x00, sl=0x03 |

I noticed that |0xf9| changed from |0x32| to |0x46| when I swapped which side of PBP it was.

I thought therefore setting it by ddcutil might change it back, but I get a validation error:

|sudo ddcutil setvcp f9 46 Verification failed for feature f9 |

Sorry to bug @rockowitz https://github.com/rockowitz - but do you have any guidance here please?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-690449944, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QXGTLQPHUZW2KCSRLSFD44NANCNFSM4J22O4BA.

rockowitz commented 3 years ago

There may be an issue related introduced by user defined features. Use the --force option.

On 09/11/2020 09:31 AM, Marcos Scriven wrote:

Sorry for the stream - one other thing I tried is |sudo ddcutil getvcp SCAN| before and after swapping between HDMI1 and HDMI2 inputs. The only thing I see changing is:

HDMI1

|VCP code 0xaf (Unknown feature ): mh=0x00, ml=0xff, sh=0x00, sl=0x00 |

HDMI 2

|VCP code 0xaf (Unknown feature ): mh=0x00, ml=0xff, sh=0xff, sl=0x00 |

So I tried setting this, to see if it would switch between HDMI 1 & 2.

However, it doesn't work directly with |getvcp| or |setsvcp|:

|sudo ddcutil getvcp 0xaf Unrecognized VCP feature code: 0xaf sudo ddcutil setvcp 0xaf 0x0000 Unrecognized VCP feature code: 0xaf |

Is there any way @rockowitz https://github.com/rockowitz to set an |Unknown feature| that /can/ be read with |sudo ddcutil getvcp SCAN|?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/100#issuecomment-691096740, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3QICPEAY74L4CXUMWLSFIRDJANCNFSM4J22O4BA.

ghost commented 3 years ago

FYI. I've much the same problem with an LG 34UM88-P. On the DisplayPort I also get

ddcutil --display 1 getvcp 60
VCP code 0x60 (Input Source                  ): Invalid value (sl=0x00)

1.) I can only send ddc commands from the active input. This is really really agravating, my second monitor a Dell S2719DGF and even my 12 years old Samsung t240 allows that. 2.) I can't change to Display Port, If I try I end up on the Thunderbolt(0xf) or HDMI1(0x10) port.

I opened a ticket and after a bit of back and fore I got it escalated, hopefully to 3rd level or the actual developers. (One can hope) I also linked this ticket as might indicate that LG has a general problem in it's DDC implementation.

34um88p-capabilities.txt

jonpas commented 3 years ago

Got a chance to test DDC on a 29UM57-P, input switching works perfectly fine on that one, all sorts of combinations. This issue seems to be limited to the newer models.

thiagopnts commented 3 years ago

I'm having the same issue with model 27GN950-B, so it seems to be something with newer LG displays

nefremov1 commented 3 years ago

Also have problems with switching input mode on27GN950-B:( Anyone has been able to find a solution?

TaiSHiNet commented 3 years ago

@nefremov1 most of these displays use the same controller so odds of fixing it on our end are nil. LG has to step up and get their firmware in order

nicklan commented 3 years ago

just to keep the catalog of displays with this issue going, my LG 34WN80C-B has exactly the same problem.

ghost commented 3 years ago

After more than four month of back and forth with german support I've got this:

Our Korean software development takes note of reports of this kind, but this does not lead to customer feedback. we do not see any need for further action here.

At first they where denying that DDC was even supported, when I've pointed them to the manual and spec sheet then they insisted that it only applied to the OSD. Finally they escalated it. I've explained in detail what my problem is, asked if there is a firmware update or an undocumented ddc feature.... and all I got is a not very nice "Don't bother us again!"

davemap commented 3 years ago

After more than four month of back and forth with german support I've got this:

I don't think your image sent :(

nicklan commented 3 years ago

or it was an amazing way of telling us that he's got no reply :)

ghost commented 3 years ago

Sorry, it's late here ;) Updated

davemap commented 3 years ago

After more than four month of back and forth with german support I've got this:

Our Korean software development takes note of reports of this kind, but this does not lead to customer feedback. we do not see any need for further action here.

At first they where denying that DDC was even supported, when I've pointed them to the manual and spec sheet then they insisted that it only applied to the OSD. Finally they escalated it. I've explained in detail what my problem is, asked if there is a firmware update or an undocumented ddc feature.... and all I got is a not very nice "Don't bother us again!"

Thank you for persisting. It's a real shame nothing came of it and I'm really disappointed in the response they've given there

jonpas commented 3 years ago

Definitely know what monitor brand to not buy from again. :)

stallion01 commented 3 years ago

Same problem with 27BN88U

hartman commented 3 years ago

Just to add to the documentation. Same for my 27UL850, but my older 27UD88 seems to work just fine.

alonpr commented 3 years ago

Seems like same for 27UN850

mariusmarais commented 3 years ago

Same for 27UL500 :(

Would bet it's everything after a certain manufacturing date.