I found some point is not make sense, 

It's hardly for implement devicesettings-hal dsGetFPColor() ,dsSetFPColor() .

How do i implement it ?

Or it's not a necessary DeviceSettingHalAPI ?

 

The point is not make sense as follows:

1)  Function of  devicesettings _dsGetFPColor() use hardcode?

Function of  devicesettings _dsGetFPColor() did not call into devicesettings-hal dsGetFPColor()
at RDK/components/generic/devicesettings/rpc/srv/dsFPD.c _dsGetFPColor()

and it used hard code!

"param->eColor = _dsPowerLedColor;"


2) TDK TestAgent didn't covert colorid to colorDetails?
RDK/tools/tdk/DS_stub/src/DeviceSettingsAgent.cpp FPI_setColor()

Some test Item verify for colorDetails, not colorid.

ex:DS_SetColor test_02.py


3) TDK TestManager condition of verify color is different?
DS_SetColor test_02.py         (compare the colorDetails for pass or not )
DS_SetColor_red test_34.py  (compare colorid  for pass or not)

 

colorid: 0 1 2 3 4   (ENMM Blue,Green,Red,Yellow,Orange)

colorDetails: "Color:255","Color:65280","Color:16711680","Color:1677184","Color:16747520"

 

Thank You!

 

  • No labels

1 Comment

  1. Deepthi Suseelan

    1) 

    Yes, dsGetFPColor api is hard-coded to powerLEDColor. Reason is that power led is considered the master led.
    (Whatever color power led is on, other led's set the same color). Regarding implementation of hal api for dsGetFPColor, it doesn't hold any meaning in RDK now.
    Because all of FP core logic resides in application and it is application driven. Application sets/decides which color to set on boot-up and which color later etc.
    It doesn't call GetFPColor and that's why it is hard-coded now.