search

robherring / generic_device

A generic android device repository
62 stars 29 forks source link

init: don't hardcode ro.hardware #5

Open aleksander0m opened 6 years ago

aleksander0m commented 6 years ago

This would allow re-using the same init.rc file as template for other hw-specific device.mk files.

robherring commented 6 years ago

No problem with this change, but I'd like to know what you plan next? What do you need different in the fstab?

aleksander0m commented 6 years ago

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.

robherring commented 6 years ago

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 < notifications@github.com> 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 .

aleksander0m commented 6 years ago

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.

robherring commented 6 years ago

On Thu, Jul 13, 2017 at 3:09 AM, Aleksander Morgado < notifications@github.com> 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 .

aleksander0m commented 6 years ago

​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

opendata26 commented 6 years ago

Any updates on this? It would be pretty useful for castor as we need to emulate the split vendor partion using the cache partion