generic_device
generic_device copied to clipboard
robherring
init: don't hardcode ro.hardware
This would allow re-using the same init.rc file as template for other hw-specific device.mk files.
No problem with this change, but I'd like to know what you plan next? What do you need different in the fstab?
Nothing in fstab per se, but I was thinking in having a different ro.hardware=xxx set and therefore use a different set of copy rules for the init files in device.mk, i.e. to avoid having them named with the "unknown" id. I could do all that, but only if the "unknown" isn't hardcoded within the init files.
Speaking of which, what would be a clean way to have additional hw-specific rules (not really generic) when using this repository? I'm thinking in e.g. the "/sys/class/backlight/pic_backlight/brightness" path from the other PR, or a custom sys.usb.controller="ci_hdrc.0" setting.
For sys.usb.controller, it is set by init. See set_usb_controller() in system/core/init/init.cpp. It picks the 1st UDC. I guess when we have 2 UDCs we'll need something better. However, most mobile SoC's only have 1 OTG/device port.
For backlight, just picking the first device should be enough for most cases. If we have multiple displays, there are lots of other problems in the Android stack.
On Wed, Jul 12, 2017 at 1:27 PM, Aleksander Morgado < [email protected]> wrote:
Nothing in fstab per se, but I was thinking in having a different ro.hardware=xxx set and therefore use a different set of copy rules for the init files in device.mk, i.e. to avoid having them named with the "unknown" id. I could do all that, but only if the "unknown" isn't hardcoded within the init files.
Speaking of which, what would be a clean way to have additional hw-specific rules (not really generic) when using this repository? I'm thinking in e.g. the "/sys/class/backlight/pic_backlight/brightness" path from the other PR, or a custom sys.usb.controller="ci_hdrc.0" setting.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robherring/generic_device/pull/5#issuecomment-314856196, or mute the thread https://github.com/notifications/unsubscribe-auth/AMpRMsTSomT1ZKHrvlhXTaueh0gJtUrvks5sNQ_2gaJpZM4OV5c1 .
Ah, good to know about the set_usb_controller() method; looks like we were not using a branch that had that support already. Will rebuild and see if I can avoid hacking the sys.usb.controller in the init.rc file.
Regarding the backlight, I'm still not sure why permission changes via ueventd.rc didn't work for my use case, still unsure if that is supposed to work like that.
On Thu, Jul 13, 2017 at 3:09 AM, Aleksander Morgado < [email protected]> wrote:
Ah, good to know about the set_usb_controller() method; looks like we were not using a branch that had that support already. Will rebuild and see if I can avoid hacking the sys.usb.controller in the init.rc file.
Regarding the backlight, I'm still not sure why permission changes via ueventd.rc didn't work for my use case, still unsure if that is supposed to work like that.
That could also be a different branch. I don't recall whether the change to support class paths went into N. May have missed it.
Rob
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robherring/generic_device/pull/5#issuecomment-315004476, or mute the thread https://github.com/notifications/unsubscribe-auth/AMpRMo3VENw5EpzySN20w9-ugK5biGiSks5sNdCfgaJpZM4OV5c1 .
That could also be a different branch. I don't recall whether the change to support class paths went into N. May have missed it.
Ah! I see that now https://android.googlesource.com/platform/system/core/+/6de783af07bddaccfa75a08286425eeaef453ac9%5E!/
Will cherry pick and retry
Any updates on this? It would be pretty useful for castor as we need to emulate the split vendor partion using the cache partion
