Developing Auto-DisableRefresh-When-Dragging App [New Video Added]

Search This thread

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
I know some people have already discussed this in the noRefresh App thread.

But I got a new idea
I don't wanna create a module and embed that to applications

Instead, I created a new Input Device in the kernel
After that, I set the device ( dev/input/event3 ) permission to allow read / write for others.
Then, write an app using JNI to catch the Input Device and set the mode of refreshing.


The prototype proved that this idea works, as i worked out it already, but not very perfect, still in experiment
I am just in some problems of threading, as I am not a professional programmer
This is wt i have now:
http://www.youtube.com/watch?v=GkFyvRR6In8
NEW!! : http://www.youtube.com/watch?v=cucG03rg3tg

I know that my method is a bit dirty,
but at least it works XD

I hope that someone would like to help



Upload those code soon
 
Last edited:
  • Like
Reactions: Zorkman and dobbing

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
Would you like to tell me how to unpack the uRamdisk? I use both Windows and Ubuntu, any methods on these two platform is ok. Thanks!
 
Last edited:

Googie2149

Senior Member
Jan 6, 2012
291
54
This is simply amazing. Since you already have it working, polishing it shouldn't take too long (I think, I'm still a beginner programmer).
 

Renate

Inactive Recognized Developer / Recognized Contrib
Feb 3, 2012
2,855
1,279
Boston
Nexus 7 (2013)
Moto E5
I don't think /dev/input is a good place to park that.
There are any number of things that could show up there and affect order.
Why not put it in its own directory?

Maybe I'm missing something, but if we use your method you still expect applications to have to be modified to read/write from event3 to control display mode?

As it is now, you only need a single function call to switch display modes. Yes, there is a little bit of housework to do before that, but what could be simpler than a single function?
 
Last edited:

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
I think no place else is more suitable than /dev/input.
As /dev/input is the linux kernel's input system.
In the driver, I would only use the input report system but not use the I/O system.
Maybe even setup a input/event searching function to solve the problem later.

The case now is that, the touch screen originally just provide event2,
but if we need to extract move and fingerup information on upper level, it may waste some time.

In order to make the whole algorithm easier and faster, I added 1 more event in the zForce driver,
to only output FingerMove and FingerUp state.
As the reporting system is starting from the kernel, this hack would need to change uImage + uRamdisk + Add an App. The project is quite huge.


My final target is to make the application remembering your choice on what mode u need for the focusing application.
AlwaysOn / OnlyWhenDragging / AlwaysOff, so on.
Of coz the click-to-call function still work.
Isn't it a better workflow and more intuitive, isn't it the thing that we would expect?
 
Last edited:

Renate

Inactive Recognized Developer / Recognized Contrib
Feb 3, 2012
2,855
1,279
Boston
Nexus 7 (2013)
Moto E5
I already have an dev/input/event3 on my system and sometimes event4, 5, 6.
That's why I don't think that whatever it is you are doing belongs there.

Is the point to allow coders for user applications to interface with your driver?
Is this supposed to work without modifying user applications?
What information would be going in/out of event3?

Clearly I am missing something here.
 

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
Actually not necessary to be event3, the system will auto-ly create a new eventx, just in normal case, without any extra USB devices, a nook should only have up to event2. So, I use event3 as an example here.

We can later make the program auto-ly search back which is the needed eventx.

Yes, u r right, we no need to modify any other applications and this is exactly the point y i am creating this!
 
Last edited:

mrWax

Senior Member
Jan 31, 2012
147
24
always on?

Look really great. Since blinking after scrolling is incomfortable is it possible to have also "always on " mode using your new ideas?
 

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
My final target is to make the application remembering your choice on what mode u need for the focusing application.
AlwaysOn / OnlyWhenDragging / AlwaysOff, so on.
Of coz the click-to-call function still work.

Also an Over-Ride mode, for more flexible using.


But the most basic part need to be handled well now, as it is not very perfect now.
I still don't figure out how to call the e-ink driver to refresh the screen =-=
 

Renate

Inactive Recognized Developer / Recognized Contrib
Feb 3, 2012
2,855
1,279
Boston
Nexus 7 (2013)
Moto E5
Yes, u r right, we no need to modify any other applications and this is exactly the point y i am creating this!

Are you saying that your idea does not require modifying user applications?
If it doesn't, then there is no need to have a public interface.
It will be only your code talking to your code.

What is the point of this /dev/input/event3? You say that it will be writable. What's going in and out?

Some apps will be using gestures, some dragging. How are you going to keep track of that all?

I have one application that works perfectly fine now, one activity uses swipe gestures to page up/down while another activity uses drag with a user choice of A2 and display while dragging or else only panning at ACTION_UP.
All this requires less than 10 lines of code.

With multitouch, many applications don't even need A2. Even normal panning in Opera Mobile works much better now that Opera doesn't try to display while panning.
 

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
Maybe my english is too bad, cannot express the idea well.
I know, we can make such an application with noRefreshDrag working on its own well.

But how about other applications, it is impossible for us to change all applications.

So, my idea is making it system based.
My prototype is very good now, after several adjustment.

Not limited to only 1 application, but the whole system.


The approach is like this:
1. zForce driver provide extra information to InputEvent
2. A JNI catch the InputEvent
3. A service get the data and set the update mode

We only need to write 1 application to handle the setting of this chain.

This is what i mean, hope that u get what i mean now.
 

wheilitjohnny

Senior Member
Mar 13, 2011
51
32
I guess that this is the part that I don't understand.
What is this extra information?

It created an extra Event, l called it Event3 before.
Driver reports only move and finger_up to Event3.

Just providing a channel to pass an information from driver to user-space.


You may ask why not directly using the existing Event, need to create another one.
That is because, the original one only have touch and position information, parsing them back to move information need a bit of work. As the hardware provided the move information, then don't waste it.
 

Renate

Inactive Recognized Developer / Recognized Contrib
Feb 3, 2012
2,855
1,279
Boston
Nexus 7 (2013)
Moto E5
Code:
   public boolean dispatchTouchEvent(MotionEvent event)
   {
      switch(event.getAction())
      {
         case MotionEvent.ACTION_DOWN:
            break;
         case MotionEvent.ACTION_MOVE:
            break;
         case MotionEvent.ACTION_UP:
            break;
      }
      return(true);
   }
}

Isn't that everything that you could ask for?
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2
    I know some people have already discussed this in the noRefresh App thread.

    But I got a new idea
    I don't wanna create a module and embed that to applications

    Instead, I created a new Input Device in the kernel
    After that, I set the device ( dev/input/event3 ) permission to allow read / write for others.
    Then, write an app using JNI to catch the Input Device and set the mode of refreshing.


    The prototype proved that this idea works, as i worked out it already, but not very perfect, still in experiment
    I am just in some problems of threading, as I am not a professional programmer
    This is wt i have now:
    http://www.youtube.com/watch?v=GkFyvRR6In8
    NEW!! : http://www.youtube.com/watch?v=cucG03rg3tg

    I know that my method is a bit dirty,
    but at least it works XD

    I hope that someone would like to help



    Upload those code soon
    1
    I still don't figure out how to call the e-ink driver to refresh the screen =-=
    Have you tried
    Code:
    echo 1 > /sys/class/graphics/fb0/epd_refresh
    ?
    1
    Sorry...... I don't get your meaning =-=
    I am not a native english user..... so..
    maybe I upload the code for u later XDDD

    btw, here is where i am: http://www.youtube.com/watch?v=cucG03rg3tg
    It is not only for 1 application, it is system-wide
    Nearly no ghosting problem ( just when several drags that the system cannot catch up )

    Hope that you would support my idea after watching XD
    1
    Maybe my english is too bad, cannot express the idea well.
    I know, we can make such an application with noRefreshDrag working on its own well.

    But how about other applications, it is impossible for us to change all applications.

    So, my idea is making it system based.
    My prototype is very good now, after several adjustment.

    Not limited to only 1 application, but the whole system.


    The approach is like this:
    1. zForce driver provide extra information to InputEvent
    2. A JNI catch the InputEvent
    3. A service get the data and set the update mode

    We only need to write 1 application to handle the setting of this chain.

    This is what i mean, hope that u get what i mean now.

    That's a neat structure idea. What if they went a step further and simply implemented DragNoRefresh within the original NoRefresh enabler? One app with all the functionality.

    I've read the source and it seems that the NoRefresh enabler is really not much more than a wrapper to the
    Code:
    N2EpdController.enterA2Mode();
    function; it creates an invisible fullscreen view, reads taps from it and checks them against its 'gesture algorithm' and then either switches to or away from A2 mode.

    If it instead read drag or multitouch gestures we'd be set. Of course, it would still be nice for it to *automatically* detect movement on the screen; this method would not work for, say, kinetic scrolling, where the screen keeps moving even after the drag has finished. To alleviate this issue, we could poll the framebuffer around where the drag was and near the borders of the screen for a short time after the gesture finished. As long as change is read, A2 is kept activated.

    Talking out of my rear end here, I'm sure y'all can think of cases where the above method would fail. I'd still be willing to dig in and hash up the described code, though
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone