Affichage des articles dont le libellé est control. Afficher tous les articles
Affichage des articles dont le libellé est control. Afficher tous les articles

mardi 25 mars 2014

[MOD] Xposed control in SETTINGS [KK] topic




Hi guys...

As I hate to have million apps in app drawer... I built simple MOD to add Xperia framework control in settings...


CAUTION :
This MOD is only for 14.3.A.0.681
Don't say I didn't warned you if you experience any problem on 4.3 or 4.2.2 firmwares


 












INSTRUCTIONS
1. Download settings.apk
2. Copy settings.apk to /system
3. Change permissions to 0644
4. MOVE settings.apk to /priv-app
5. Restart and...


That's it ;)

Enjoy...



DOWNLOAD
SETTINGS with Xposed



Don't use my MODs/ANIMATIONs/APPs in your ROMs/MODs/APPs without permission



Hit TNX if you are using or just like this





lundi 24 mars 2014

Module With Expanded Volume Control topic




I am looking for the module that adds Notification Levels on the Volume menu. Can't remember which one I had installed that provided it.





dimanche 23 mars 2014

Re: Question about Source Control topic




On Mon, Mar 24, 2014 at 11:19 AM, Cameron Simpson <(E-Mail Removed)> wrote:
> I'm particularly fond of "hg record" (or the similar extension, "hg
> crecord"), which lets you commit just parts of a modified file.
>
> When I'm in a debugging branch, it gradually turns into a huge diff.
> "hg record" lets me commit specific parts of a diff in a single
> commit. Every so often I spent a little while cleaning out related
> changes that are going to stay so that the final diffness consists
> of debug statements and hacks-in-progress; much smaller.
>
> So I'll pick a file and run an "hg record that-file" and pick all
> the diff parts that involve, say, removing some parameter. And in
> goes a single commit with just that feature change. Lather, rinse,
> repeat for other small concrete changes.
>
> And then my "hg diff" is back to being managably readable.
>


Absolutely agree. With git, the same functionality can be done by
making use of the staging area; you can either add an entire file (all
its changes), or do a partial add with "git add -p" or (more
conveniently, but requires a GUI) "git gui". I do that *very*
frequently. The only thing I would really like is a simple way to say
"stage/commit the lines from here to there"; with git gui, I can
either stage an entire hunk (everything until the next point where
there's enough unchanged lines that the context breaks) or a single
line (either an insertion or a removal). Gets tedious when you want to
stage half of a large hunk. But other than that, yes, the
functionality is awesome, letting you fidget your edits into readable
commits.

ChrisA





Re: Question about Source Control topic




On 24Mar2014 11:30, Chris Angelico <(E-Mail Removed)> wrote:
> On Mon, Mar 24, 2014 at 11:19 AM, Cameron Simpson <(E-Mail Removed)> wrote:
> > I'm particularly fond of "hg record" (or the similar extension, "hg
> > crecord"), which lets you commit just parts of a modified file.
> >
> > When I'm in a debugging branch, it gradually turns into a huge diff.
> > [...] Every so often I spent a little while cleaning out related
> > changes that are going to stay so that the final diffness consists
> > of debug statements and hacks-in-progress; much smaller. [...]

>
> Absolutely agree. With git, the same functionality can be done by
> making use of the staging area; you can either add an entire file (all
> its changes), or do a partial add with "git add -p" or (more
> conveniently, but requires a GUI) "git gui". [...]
> The only thing I would really like is a simple way to say
> "stage/commit the lines from here to there"; with git gui, I can
> either stage an entire hunk (everything until the next point where
> there's enough unchanged lines that the context breaks) or a single
> line (either an insertion or a removal). Gets tedious when you want to
> stage half of a large hunk. [...]


"hg record" has the same issue; you get to approve or ignore single
diff chunks.

However, there's no fundamental technical reason you can't pick and
choose arbitrary lines.

Based on things I've experienced use "hg record", it pretty clearly
walks the user through the diff picking/rejecting chunks, and then
temporarily replaces the target file(s) with versions containing
only the selected diff chunks, and commits the files. Then it
restores the original modified file, whose diff from the "tip" is
now reduced.

With some work, that could be done on a line-by-line basis.

Cheers,
--
Cameron Simpson <(E-Mail Removed)>

I've always been a big Greenaway fan - I've seen and enjoyed "The Falls" for
crying out loud. - Peter Alexander Merel <(E-Mail Removed)>





Re: Question about Source Control topic




On 24Mar2014 09:56, Chris Angelico <(E-Mail Removed)> wrote:
> On Mon, Mar 24, 2014 at 1:58 AM, Albert-Jan Roskam <(E-Mail Removed)> wrote:
> > One more thing (so this is not entirely a double post!). While reading these books I found that the authors were pretty religious about Clean Commits. I mean, ok, it's not a good idea to do one huge monolithic commit each month, but I felt they were exaggerating. But maybe I'm wrong and clean commits become more important when the number of collaborators get bigger. It's just so easy to fix something, and e.g. correct that typo in a docstring while you're at it.
> >

>
> It's important even with a single editor. When you go back and look at
> a commit, you should be able to read the summary and know immediately
> whether a particular line in it should have been edited or not.
> Combining changes into a single commit makes that harder.
>
> Commits are cheap. Do more of 'em rather than less.


I'm particularly fond of "hg record" (or the similar extension, "hg
crecord"), which lets you commit just parts of a modified file.

When I'm in a debugging branch, it gradually turns into a huge diff.
"hg record" lets me commit specific parts of a diff in a single
commit. Every so often I spent a little while cleaning out related
changes that are going to stay so that the final diffness consists
of debug statements and hacks-in-progress; much smaller.

So I'll pick a file and run an "hg record that-file" and pick all
the diff parts that involve, say, removing some parameter. And in
goes a single commit with just that feature change. Lather, rinse,
repeat for other small concrete changes.

And then my "hg diff" is back to being managably readable.

Cheers,
--
Cameron Simpson <(E-Mail Removed)>

Wagner's music is better than it sounds. - Mark Twain





mercredi 19 mars 2014

Re: Question about Source Control topic




On Wed, Mar 19, 2014 at 5:41 PM, Frank Millman <(E-Mail Removed)> wrote:
> I have decided to stick with Mercurial, simply because that is what I used
> in my previous attempt and I felt comfortable with it.


That's the best reason for choosing, really.
https://github.com/Rosuav/Gypsum/commit/0f973
> Also I believe that
> Python itself uses it, so if it is good enough for them ...


Mercurial is used by a good number of high-profile projects. You're
probably thinking of CPython, the implementation, but
Python-the-language is built on top of Mercurial too, with such as the
PEP repo and the web site (although I understand the latest version of
the web site is managed in git). Both git and hg are used by plenty of
solid projects, including the Linux kernel (git's original purpose),
themselves (git's development is managed in git, hg's is managed in
hg), and plenty of other big projects. This is one reason why I always
push people to either of those two, rather than to an unknown or
proprietary system that might have problems.

> I realise now that my initial problem had nothing to do with SCM/VCS, and
> everything to do with my lack of knowledge of basic networking protocols. As
> I understand it now, if I want to share the repository over a network, I can
> choose between SSH and HTTP. I like the following quote from Joel Spolsky -
>
> "The quick-and-dirty way to make a central repository is to use Mercurial's
> built in web-server. ... I'm going to configure the server to allow anybody
> in the world to do anything they want to it. ... Needless to say, this is
> rather unsafe, but if you're on a nice protected LAN at work and there's a
> good firewall and you trust everybody on your LAN, this is reasonably OK."
>
> This describes my situation well, so to keep things simple I will start with
> this.


Yep! People complain loudly about the insecurity of protocols like
FTP, but properly-firewalled networks with all members trusted are
more common than you might think - all you need is a basic home-grade
NAT router and a sysadmin whose competence exceeds the sensitivity of
your content.

> To recap my basic setup, I have machine A which holds the source directory,
> machine B which is used to edit the program, and machines B and C which are
> both used to run the program.
>
> Initially, to prove that I understand the concept, I propose to install
> Mercurial on all three machines. Machine A will hold the central repository,
> which I will clone onto machines B and C. After editing on B, I will 'push'
> to A, and then from C 'pull' from A to get the latest version.


Right. That's a nice standard setup. There'll be plenty of tutorials
that can walk you through setting that up. (Don't forget, btw, that
most Linux distributions will include Mercurial - just "apt-get
install mercurial" or "yum install mercurial".)

> If this works, I will simplify it to make my life easier. My first thought
> was to remove the clone from machine C and set up an nfs share pointing to
> the working directory on machine A, so I don't need the 'pull' step. Then I
> thought, why not just point to the working directory on machine B, so then I
> can test the changes on C directly, without even having to 'push'. I realise
> that this is defeating the object of version control, but I think it makes
> sense. I will still use version control to maintain a full history of the
> project on machine A.


It doesn't defeat the object of version control as long as you always
make logical, conceptual commits. However, it does introduce a
dependency (the NFS share) and the associated messes of file locking
and so on, so I personally would prefer to deploy a file-transfer
system, maybe like the one I described earlier, or maybe something
more like FTP. But do whatever makes sense for you.

> Over the last few years I have frequently 'trashed' whole sections
> of my code and rewritten them, which I suspect would not endear me to
> someone attempting to collaborate with me. However, the broad framework is
> starting to settle down now, so I am starting to think about putting it out
> there.


That's not in itself a problem. This commit made quite a few changes,
all at once:

https://github.com/Rosuav/Gypsum/commit/0f973

It does mean that anyone who's collaborating with you will need to
keep a close eye on what goes on, but that's true of any fast-moving
project. As things get more stable, it'll be easier to join in.

ChrisA





mardi 18 mars 2014

Re: Question about Source Control topic





"Frank Millman" <(E-Mail Removed)> wrote in message
news:lg6s09$irl$(E-Mail Removed)...
> Hi all
>
> I know I *should* be using a Source Control Management system, but at
> present I am not. I tried to set up Mercurial a couple of years ago, but I
> think I set it up wrongly, as I got myself confused and found it more of a
> hindrance than a help. Now I am ready to try again, but I want to avoid my
> earlier mistakes.
>


Many thanks to all for the responses. I have a much better feel for it now.
If anything, I have moved from being confused because I did not understand
it, to being confused because there are so many options I am not sure which
to select. However, I consider this to be progress!

I have decided to stick with Mercurial, simply because that is what I used
in my previous attempt and I felt comfortable with it. Also I believe that
Python itself uses it, so if it is good enough for them ...

Before actually plunging in, I would like to summarise what I think I have
understood, and what steps I propose to take.

I realise now that my initial problem had nothing to do with SCM/VCS, and
everything to do with my lack of knowledge of basic networking protocols. As
I understand it now, if I want to share the repository over a network, I can
choose between SSH and HTTP. I like the following quote from Joel Spolsky -

"The quick-and-dirty way to make a central repository is to use Mercurial's
built in web-server. ... I'm going to configure the server to allow anybody
in the world to do anything they want to it. ... Needless to say, this is
rather unsafe, but if you're on a nice protected LAN at work and there's a
good firewall and you trust everybody on your LAN, this is reasonably OK."

This describes my situation well, so to keep things simple I will start with
this.

To recap my basic setup, I have machine A which holds the source directory,
machine B which is used to edit the program, and machines B and C which are
both used to run the program.

Initially, to prove that I understand the concept, I propose to install
Mercurial on all three machines. Machine A will hold the central repository,
which I will clone onto machines B and C. After editing on B, I will 'push'
to A, and then from C 'pull' from A to get the latest version.

If this works, I will simplify it to make my life easier. My first thought
was to remove the clone from machine C and set up an nfs share pointing to
the working directory on machine A, so I don't need the 'pull' step. Then I
thought, why not just point to the working directory on machine B, so then I
can test the changes on C directly, without even having to 'push'. I realise
that this is defeating the object of version control, but I think it makes
sense. I will still use version control to maintain a full history of the
project on machine A.

I appreciated Mark's comments about hosting his project on code.google.com -
not just the mechanics, but the benefits that he experiences from sharing
his code. I am actually getting closer to being able to do that with my
project. Over the last few years I have frequently 'trashed' whole sections
of my code and rewritten them, which I suspect would not endear me to
someone attempting to collaborate with me. However, the broad framework is
starting to settle down now, so I am starting to think about putting it out
there. Then the question is which hosting service to use - there are so many
of them. I will probably come back here for more advice when I get to that
stage.

Frank








Re: Question about Source Control topic




On Tue, Mar 18, 2014 at 6:55 PM, Steven D'Aprano <(E-Mail Removed)> wrote:
> I don't think that *version* control is the right model to describe what
> hg and git do, although it may be appropriate for subversion. hg doesn't
> manage *versions*, it manages changes to source code ("changesets").


Meh... Is there any real difference? With git, I can check out any
tree state I like ("give me the 50th parent of the current HEAD"), so
in that sense it effectively stores versions - at least, it can
retrieve or recreate versions. Does it store versions and optimize
them by recording only the difference, or record differences and
replay them to recreate a state? Two sides of the same coin.

ChrisA





Re: Question about Source Control topic





"Chris Angelico" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) m...
> On Tue, Mar 18, 2014 at 4:39 PM, Frank Millman <(E-Mail Removed)> wrote:
>> Two quick questions -
>>
>> 1. At present the source code is kept on one machine (A), but only
>> accessed
>> from the two other machines (B and C).
>>
>> Does it make sense to create the central repository on A, but *not*
>> install
>> the SCM on A? Install separate copies of the SCM on B and C, and allow
>> them
>> both to set up their own clones. I only develop on B, so only B would
>> 'push', but both B and C would 'pull' to get the latest version.

>
> I don't know about Mercurial, but with git, installing the software on
> A lets it work more efficiently (otherwise it has to do all the work
> remotely, ergo unnecessary traffic). Advantage of free software is
> that you don't have to check license agreements - just go ahead,
> install it everywhere. But if for some reason that would be a problem,
> you can look into running it over basic SSH or something.
>


Excuse my ignorance, but how does it actually work?

Do you set up some kind of client/server relationship, and if so, how do the
clients (machines B and C) access the software on machine A?

I know that Mercurial can run its own web server, and clients can access it
through http. It that what you are suggesting? That would be quite a change
for me, as on my linux box I do all my work from the command line on a
console.

These are the kind of stumbling blocks that prevented me from succeeding in
my previous attempt. I have a vague recollection that I set it up on machine
A, but then hit a problem because machines B and C both accessed the same
directory, but with different names - on Windows, a mapped drive and on
linux a mounted nfs directory. I had to provide a 'path' name to set up
Mercurial in the first place, but I could not find one that suited both
clients.

I feel that I have just not grasped the basics yet, so any assistance that
puts me on the right path is appreciated.

Frank








Re: Question about Source Control topic





"Andriy Kornatskyy" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Frank,
>
> I would suggest start with an account on https://bitbucket.org. It
> supports private repositories so you should be good there.
>
> From other hand you can setup own infrastructure for SCM, read more here:
> http://mindref.blogspot.com/2013/10/...mercurial.html
>


Thanks, Andriy.

I followed your link, which took me to another link which took me to
RhodeCode - https://rhodecode.com/

It looks interesting. I wll investigate that and bitbucket further.

Frank








Re: Question about Source Control topic




On Tue, Mar 18, 2014 at 5:42 PM, Frank Millman <(E-Mail Removed)> wrote:
> Excuse my ignorance, but how does it actually work?


Ignorance not only excused, but welcomed. :) However, caveat: I know
how git is set up, but not hg. Someone else can fill in the details;
for now, I'll explain git and hope that hg is broadly similar. I
expect it will be.

> Do you set up some kind of client/server relationship, and if so, how do the
> clients (machines B and C) access the software on machine A?


For read-only access, git can run its own protocol, but for read/write
it's most common to run it over SSH. Every pull or push is implemented
by git calling on ssh to run either 'git send-pack' or 'git
receive-pack' on the other end. (It's common to set it up with a
restricted shell that can *only* run those commands, although I also
find this usage convenient for cloning between two computers that I
control, rather than fetching from upstream. It's immensely faster
downloading something over a virtualized gigabit ethernet link than
over the internet!)

So it goes by the rules of SSH. There's a user account on the target
computer, which owns all the files in the repository. That user
account might have a password on it (which you type in every time you
pull/push), or you might use public/private keys to authenticate, or
whatever else you've set up. That part isn't git's responsibility. On
Linux systems, it's usually pretty easy to set up openssh and a
dedicated account; on other servers, I assume it can't be hard to get
something going.

> I know that Mercurial can run its own web server, and clients can access it
> through http. It that what you are suggesting? That would be quite a change
> for me, as on my linux box I do all my work from the command line on a
> console.


You'd still do everything from the command line. You type "git clone
blahblah" or "hg clone blahblah", and everything happens under the
covers. The only way you'd know the difference is if the "blahblah"
part identifies the protocol (which it usually will, but that's
somewhat beside the point).

> These are the kind of stumbling blocks that prevented me from succeeding in
> my previous attempt. I have a vague recollection that I set it up on machine
> A, but then hit a problem because machines B and C both accessed the same
> directory, but with different names - on Windows, a mapped drive and on
> linux a mounted nfs directory. I had to provide a 'path' name to set up
> Mercurial in the first place, but I could not find one that suited both
> clients.
>
> I feel that I have just not grasped the basics yet, so any assistance that
> puts me on the right path is appreciated.


Yeah, a distributed repository solves that. You could have three
entirely different path names on the three computers, and nothing will
care. (You have to be careful to use relative paths everywhere
internally, of course, but you probably do that already.) It's pretty
efficient once you get used to it; I recommend poking around on the
internet for a git tutorial or an hg tutorial, depending on which you
go with. It's not too hard, but there are a lot of commands to keep
track of. Here's a helpful quick reference to the differences between
the two:

https://github.com/sympy/sympy/wiki/...-rosetta-stone

As a git-familiar and hg-novice, I keep that handy every time I'm
working with hg on anything more complicated than "keep up with the
changes".

ChrisA





Re: Question about Source Control topic





"Ben Finney" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Frank Millman" <(E-Mail Removed)> writes:
>
>> I feel that I have just not grasped the basics yet, so any assistance
>> that
>> puts me on the right path is appreciated.

>
> Here is "Hg Init", a tutorial for Mercurial <URL:http://hginit.com/>.
>
> ("source control" is not the most common term for this; what we're
> talking about is a "version control system", or VCS. But some Git users
> may disagree.)
>


Thanks, Ben, that is a really nice tutorial.

I was calling it an SCM because that is how Mercurial describes it - from
their home page "Mercurial is a free, distributed source managment control
tool". I do agree that 'version control' makes more sense.

Frank








Re: Question about Source Control topic




On Tue, Mar 18, 2014 at 5:47 PM, Ben Finney <(E-Mail Removed)> wrote:
> (“source control” is not the most common term for this; what we're
> talking about is a “version control system”, or VCS. But some Git users
> may disagree.)


People use different terms depending on their backgrounds, I think.
I've heard a good few words used to describe fundamentally the same
thing, and none is really perfect.

ChrisA





lundi 17 mars 2014

Re: Question about Source Control topic





"Chris Angelico" <(E-Mail Removed)> wrote in message
news:CAPTjJmqPca5cnNWu8T5BZhpH665X0=mrf7bJaLqVrQVM (E-Mail Removed)...
> On Tue, Mar 18, 2014 at 12:06 AM, Frank Millman <(E-Mail Removed)>
> wrote:

[...]
>>
>> So where should I install the SCM, and how should I set it up so that I
>> can
>> access the latest version from any machine?

>
> First off: You can save yourself a huge amount of trouble now! Modern
> source control systems are distributed (DVCS - Distributed Version
> Control System), which means that you have a much simpler setup: every
> machine that uses it has a full clone of the repository.
>
> By the sound of it, you don't have any history at the moment, so I'll
> assume you just start using either git or hg from where you are. The
> first thing to do is to get a local copy of the current source tree.
> I'd start with a Linux system, because everything seems to be easier
> there...
>

[...]

Thanks, Chris. I appreciate the detailed explanation.

Two quick questions -

1. At present the source code is kept on one machine (A), but only accessed
from the two other machines (B and C).

Does it make sense to create the central repository on A, but *not* install
the SCM on A? Install separate copies of the SCM on B and C, and allow them
both to set up their own clones. I only develop on B, so only B would
'push', but both B and C would 'pull' to get the latest version.

2. Being a typical lazy programmer, I frequently go through the following
cycle. I work on a section of code by editing it on B. Then I test it by
running it on C. Instead of meticulously checking my code I let python find
the errors, so I run it on C, it crashes with a traceback, I fix the error
on B and rerun it on C until it is working to my satisfaction.

It seems that I will have to change my approach. Edit on B, 'push' on B,
'pull' on C, run from C. It sounds more cumbersome, but maybe that is the
price I have to pay.

Have I got those two right?

Thanks

Frank








Re: Question about Source Control topic




On Tue, Mar 18, 2014 at 4:39 PM, Frank Millman <(E-Mail Removed)> wrote:
> Two quick questions -
>
> 1. At present the source code is kept on one machine (A), but only accessed
> from the two other machines (B and C).
>
> Does it make sense to create the central repository on A, but *not* install
> the SCM on A? Install separate copies of the SCM on B and C, and allow them
> both to set up their own clones. I only develop on B, so only B would
> 'push', but both B and C would 'pull' to get the latest version.


I don't know about Mercurial, but with git, installing the software on
A lets it work more efficiently (otherwise it has to do all the work
remotely, ergo unnecessary traffic). Advantage of free software is
that you don't have to check license agreements - just go ahead,
install it everywhere. But if for some reason that would be a problem,
you can look into running it over basic SSH or something.

> 2. Being a typical lazy programmer, I frequently go through the following
> cycle. I work on a section of code by editing it on B. Then I test it by
> running it on C. Instead of meticulously checking my code I let python find
> the errors, so I run it on C, it crashes with a traceback, I fix the error
> on B and rerun it on C until it is working to my satisfaction.
>
> It seems that I will have to change my approach. Edit on B, 'push' on B,
> 'pull' on C, run from C. It sounds more cumbersome, but maybe that is the
> price I have to pay.
>
> Have I got those two right?


That would be the simplest to set up. But here are two alternatives:

1) My current setup for developing Gypsum involves development on
Sikorsky, on Linux, and everything gets tested there. Then every once
in a while, I pull changes to Traal, and test on Windows. If there's a
problem, that's a separate commit fixing a separate issue ("Implement
pause key handling" / "Fix pause key handling on Windows"). That works
fairly well when you can do >90% of your testing on your development
box.

2) At work, we had a system for rapid development across two machines,
pretty much how you're describing. To make that work, I wrote a
three-part rapid send/receive system: a daemon that runs on the dev
system, a client that runs on the test system and connects to the
daemon, and a triggering notification that runs on the dev and tells
the daemon to do its work. (That could be done with a process signal,
but I wanted to send it some parameters.) When the daemon gets
notified to send its stuff across, it writes out the full content of
all changed files (mangled somewhat because my boss was paranoid -
well, as far as I know he's still utterly paranoid, but he's not my
boss any more) to the socket connection, and the receiver plops them
onto the disk and SIGHUPs the appropriate processes to tell them to
reload code.

The second option takes some setting up, though I'd be happy to help
out with the code. But it's really easy to use. You shoot stuff across
to it and off it all goes. The way I described above, it's quite happy
to have multiple simultaneous clients, and it's happy for those
clients to be behind NAT - so you can run half a dozen VMs with
different configurations, and have them all get the code together. And
you can put the trigger into a makefile to be run at the end of some
other tasks, or have it do some sanity checking, or whatever you like.
Very flexible and powerful.

ChrisA





mercredi 12 mars 2014

samedi 8 mars 2014

Samsung Smart Home Control (Phone) topic




HI guys

Where or how can i get this app to work on my S4?

https://play.google.com/store/apps/d...llShareControl

My device is not rooted etc, not sure if there is a universal .apk somewhere?

It seems to be only supporting S3?





jeudi 6 mars 2014

I'm looking for an app or have an app idea for external control of an android. topic




Hi XDA,

Since i'm working and barely have time to look at my phone whilst i'm working, i would like to have a way to control music playback (such as next song, play/pause, louder, quieter) without taking it out of its etui. I'm thinking it would be possible to control the phone via tapping on it, while it's in the pocket.
Is there any app out there, where it would be possible to do so?
If not, i think it would be easy to make such an app.. using either the microphone to pick up the tapping noise or the accelerometer in some way.

Thanks,





lundi 24 février 2014

Xposed LED Control topic




Anyone have any experience with this? I would like to set my notifications to being the same color, I'm not much for differentiating, I'm looking into this, I read LF is pretty good, however I read it can destroy a battery life, and I'd like to stick with modules for now, I've probably grown prejudiced since I went rooted along with xposed lol. Any input would be great. Thanks!

Sent from my Nexus 5 using Tapatalk





lundi 10 février 2014

GPU control. topic




Is there a way to control what the gpu processes in the stock rom/kernal? I was messing around with Hellfire kit kat (excellent rom btw) and it had an option in the settings for all animations and such be controlled by the gpu not the cpu.

Sorry if this should have went into the help thread, apologies.

Sent from my LG-D800 using xda premium