Thanks for the tip. I am trying to understand how to make the change. If I understand correctly, this is the code flow:
Window Manager - Display class -(JNI) - Surface Flinger - DisplayHardware - Kernel display driver However, if the screen size changes, all these levels should be updated all together, right? Then what is the right sequence to do this? From Window Manager down to the kernel driver, or the other direction? If I update the framebuffer size using ioctl() call, how such change is propagated? Thanks, Ron On Dec 29, 3:02 pm, Dianne Hackborn <hack...@android.com> wrote: > It uses the Display class. Display is implemented partly with JNI code to > call on to surface flinger. > > > > On Tue, Dec 28, 2010 at 12:49 PM, kfpan <ronaldthepa...@gmail.com> wrote: > > The code in this area is complicated. Although I view myself a good > > code hacker, I am lost here. > > > From where the Window Manager gets its screen dimension in the first > > place? The Window Manager is in Java, but the surfaceflinger is in C. > > Are they supposed to communicate? > > > Thanks, > > Ron > > > On Dec 18, 4:00 pm, Dianne Hackborn <hack...@android.com> wrote: > > > Note that I believe for the time being devices that can change their > > screen > > > size sufficiently to change it into a different size bucket will not be > > > considered compatible. > > > > Anyway, yes, the approach is basically that -- you need to plumb some new > > > event to the window manager to tell it the screen size has changed, and > > then > > > have it re-evaluate the size and do the appropriate changes similar to > > > orientation changes. > > > > On Sat, Dec 18, 2010 at 3:22 PM, G2 <grego...@gentil.com> wrote: > > > > There are other people (including me) who are interested by such > > > > feature. Read this: > > > > >http://groups.google.com/group/rowboat/browse_thread/thread/5fd05e929. > > .. > > > > > Dianne might comment more but I would say that yes, it's probably the > > > > right direction - if I had more time, I would search on this > > > > direction. I also think that it's not super complex because of the > > > > architecture, all apps are Window based. Just imagine the screen size > > > > modification event as a rotation event. My guess is that it's a 100- > > > > line patch not a 5000-line patch... But somebody needs to write it. > > > > > Bottom-line, if you allow me to give you a piece of advice, understand > > > > how rotation works and apply the same idea. And please post your > > > > results if any! > > > > > Grégoire > > > > > On Dec 17, 2:01 pm, kfpan <ronaldthepa...@gmail.com> wrote: > > > > > I am porting android to a netpc platform. One requirement is for the > > > > > pc to support different screen sizes without rebooting the machine. > > > > > For example, if I plug in a larger size monitor, I should be able to > > > > > reconfigure the screen so that new display fits the larger screen, > > > > > with restarting Android. I have managed to change the frame buffer > > > > > size. But I am not sure how to notify WindowManager to update its > > > > > window with the new size. I am going through WindowManager.java and > > > > > WindowManagerService.java. Is this the right direction? How can be > > re- > > > > > init the window screen with the new size? Is there an event that can > > > > > achieve this? > > > > > > Thanks, > > > > > Ron > > > > > -- > > > > unsubscribe: > > > > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > > <android-porting%2bunsubscr...@googlegroups.com<android-porting%252bunsubscr...@googlegroups.com> > > > > > website:http://groups.google.com/group/android-porting > > > > -- > > > Dianne Hackborn > > > Android framework engineer > > > hack...@android.com > > > > Note: please don't send private questions to me, as I don't have time to > > > provide private support, and so won't reply to such e-mails. All such > > > questions should be posted on public forums, where I and others can see > > and > > > answer them. > > > -- > > unsubscribe: > > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com> > > website:http://groups.google.com/group/android-porting > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
