Page tree

Skip to end of metadata
Go to start of metadata

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.


3) TDK TestManager condition of verify color is different?
DS_SetColor         (compare the colorDetails for pass or not )
DS_SetColor_red  (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. 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.