I don't know, I have never tried to do this or put much thought into how it would be done. Whichever direction you go, you'll need to plumb though various things to make it work.
On Thu, Dec 30, 2010 at 3:03 PM, kfpan <ronaldthepa...@gmail.com> wrote: > 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> > > > > > <android-porting%2bunsubscr...@googlegroups.com<android-porting%252bunsubscr...@googlegroups.com> > <android-porting%252bunsubscr...@googlegroups.com<android-porting%25252bunsubscr...@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> > <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
