[ROM] CyanogenMod 7 for the Samsung Vibrant :: V7.1.0.1 (10 Oct 2011)

Search This thread
By:
Advanced…
eservant

eservant

Senior Member
Aug 31, 2010
89
31
Va Beach
Google Pixel 7
wifi and 3g internet calling.

When using cm7 native dialer (doesn't happen with sipdroid), whoever I am talking to hears an echo of their voice(I can't hear it). If I turn down the volume to half it disappears, but I can barely hear the person I am talking to. Don't know if it is a bug, was just wondering if any one else was having the same issue.
 
buggzero

buggzero

Senior Member
Sep 3, 2007
105
0
40
Colorado Springs, CO
yosup said:
I think everything's moving into CM9 now. The last CM7 nightly was from 2/26/12 I believe. Haven't seen any Nightlies posted for CM9 yet - though I could be mistaken.
Click to expand...
Click to collapse

CM for Vibrant was stopped due to E911 issues, which are driver related, and until samsung provides updates (which chances are likely hell will freeze over first) the project was halted, and no plans for cm9 support were made. That was the last I heard.
 
yosup

yosup

Senior Member
Dec 9, 2011
559
509
buggzero said:
CM for Vibrant was stopped due to E911 issues, which are driver related, and until samsung provides updates (which chances are likely hell will freeze over first) the project was halted, and no plans for cm9 support were made. That was the last I heard.
Click to expand...
Click to collapse
Hmm ... I believe they figured out the E911 issue and that's why they started up the nightlies again starting with #229.

From my understanding, FaultException is now maintaining the CM dev for the Vibrant. See his comments below ...

FaultException said:
It isn't. It was Genesis3 and renard that discovered the fix for E911.

Pawitp did not buy a vibrant, I volunteered to maintain CyanogenMod for the vibrant.

We should see CM9.
Click to expand...
Click to collapse

Also ... a tease that CM9 is coming ...

FaultException said:
... A CM9 alpha for Vibrant (like already exists for Captivate, and i9000) will probably be put up later this month ...
Click to expand...
Click to collapse
 
  • Like
Reactions: buggzero
flapane

flapane

Senior Member
Jul 16, 2010
360
51
Naples/Dortmund
www.flapane.com
buggzero said:
CM for Vibrant was stopped due to E911 issues, which are driver related, and until samsung provides updates (which chances are likely hell will freeze over first) the project was halted, and no plans for cm9 support were made. That was the last I heard.
Click to expand...
Click to collapse

AFAIK new nightlies have been released in February just because E911 bug has been already fixed (I cannot say more, no 911 here in Italy).
Maybe they decided to concentrate on CM9 alpha builds only.
 
FaultException

FaultException

Inactive Recognized Developer
Jan 13, 2012
1,238
2,006
:eek: There's still people that think the project is dead!?

Catch up:
* CM dropped support because of E911
* E911 cause found by Genesis3 & renard
* CM support reinstated as of mid February.
* Nightlies are weird right now, they'll probably be back up eventually, but I'm not really any part of that.
* There are some new nightlies here, you should use those rather than Stable till 7.2 is put out. (Use the second to newest nightly, the newest nightly is bugged and will make your status bar FC)
* CM9 alpha has been available since February 17th.
 
Last edited:
  • Like
Reactions: jvpde, akfelipe and yosup
akfelipe

akfelipe

Senior Member
Feb 11, 2011
71
14
FaultException said:
:eek: There's still people that think the project is dead!?

Catch up:
* CM dropped support because of E911
* E911 cause found by Genesis3 & renard
* CM support reinstated as of mid February.
* Nightlies are weird right now, they'll probably be back up eventually, but I'm not really any part of that.
* There are some new nightlies here, you should use those rather than Stable till 7.2 is put out. (Use the second to newest nightly, the newest nightly is bugged and will make your status bar FC)
* CM9 alpha has been available since February 17th.
Click to expand...
Click to collapse


Shouldn't be a surprise that people think CM died on us.... maybe creating a new thread by say, the maintainer :)

especially when people started flocking to ICS roms, a new fresh CM 7 thread would be nice(a atinm like thread ). you know for us that want to stick with a stabler cm gingerbread goodie, until cm9 "matures".
 
R

rogerchew

Senior Member
Aug 15, 2010
398
20
so how is the stability now? battery life almost on par with froyo roms? went to ics, getting a lot of wakelock issues with gps still. if anyone is still running cm7, would love to hear your experiences.
 
theking_13

theking_13

Senior Member
Dec 20, 2011
7,403
350
Florida
rogerchew said:
so how is the stability now? battery life almost on par with froyo roms? went to ics, getting a lot of wakelock issues with gps still. if anyone is still running cm7, would love to hear your experiences.
Click to expand...
Click to collapse

The stability has always been great, as you would expect from CM7. The battery isn't to great, I found myself staying on Froyo (Bionix NextGen v2 to be specific) until the early stages of ICS. I would recommend ICS Passion, its super stable, and a great daily driver. The ICS development is the biggest thing that I miss about my Vibrant.

Sent from my LG-P999 using XDA
 
H

hurtz777

Senior Member
Feb 11, 2011
1,122
603
Oklahoma City, OK
GPS Testing Indoors On A Cloudy Day Without Wifi Enabled On CM7 Nightly Build 236

STOCK Build 236
13 Satellites visible, but no lock

STOCK Build 236 + borked-yagf2
14 Satellite visible, top 2 satellites up to 22db turn on and off, but no lock

STOCK Build 236 + yagf2
13 Satellites visible, locked in 10 secs and locked up to 9 satellites down to 7m accuracy. GPS would lock 9 satellites after about 2 minutes coming out of deep sleep but would average only 30-40m accuracy.

STOCK Build 236 + CM7_VIBRANT_20111204_NEO_XX.1_VC-led-notif kernel + yagf2
14 Satellites Visible, locked in 10 secs and locked up to 9 satellites down to 6m accuracy. GPS would lock up to 9 satellites after only 30 seconds coming out of deep sleep and it even got the same 6m accuracy as before deep sleep!

I also tried Glitch v13.1 and CM7_VIBRANT_20111203_NEO_18_VC-led-notif_didle kernel with Build 236 and they both locked between 6-7m accuracy but they couldn't initialize GPS after deep sleep. The conclusion to my GPS testing is if GPS lock accuracy is important to you and you need it to work quickly and accurately after deep sleep use Build 236 + CM7_VIBRANT_20111204_NEO_XX.1_VC-led-notif + yagf2. If you don't mind a a slower first lock and less accuracy after deep sleep you can use the stock kernel on Build 236 + yagf2. Could someone else please test out STOCK Build 236 + CM7_VIBRANT_20111204_NEO_XX.1_VC-led-notif + yagf2 and see if you get the same results I do. Thank you FaultException for being the Vibrant CM7/9 man!
 
  • Like
Reactions: FaultException
akfelipe

akfelipe

Senior Member
Feb 11, 2011
71
14
new thread? why are we using the 7.1 RC thread to talk about cm 7 nightlies/7.2 stuff...
 
You must log in or register to reply here.

Similar threads

atinm
  • Locked
[NIGHTLY][ROM] CyanogenMod 7 for Samsung Vibrant (vibrantmtd)
Replies
9K
Views
1M
D
dpaul007
TGA_Gunnman
[Drivers] MS Windows x86 and x64 USB Drivers for Samsung Galaxy S
Replies
131
Views
2M
Jack_O_Neill
Jack_O_Neill
neobuddy89
[ROM][03-MAR][4.0.3] ICS Passion v13.1 - RC1.1 - No Big Update Yet
Replies
11K
Views
2M
B
Block Builder
FaultException
[DISCONTINUED][ROM] CyanogenMod 10.1 Nightly Builds for the Samsung Vibrant
Replies
1K
Views
341K
C
CTown
FaultException
  • Locked
[NIGHTLY][ROM][4.0.4] CyanogenMod 9 for the Samsung Vibrant
Replies
2K
Views
375K
Waldos
Waldos

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 57
    C
    CyanogenMod
    Due to an issue with emergency dialing (911), the stable build is no longer supported. It is suggested you update to the latest nightly available until a new stable release is ready to receive this fix. It is very important you do not use these builds, as emergency dialing is not properly functional and could put you at risk.

    -SGS Team/Team Hacksung/Teamdouche

    CyanogenMod is a free, community built, aftermarket firmware distribution of Android 2.3 (Gingerbread), which is designed to increase performance and reliability over stock Android for your device.
    Code: 
    #include <std_disclaimer.h>
/*
 * Your warranty is now void.
 *
 * I am not responsible for bricked devices, dead SD cards,
 * thermonuclear war, or you getting fired because the alarm app failed. Please
 * do some research if you have any concerns about features included in this ROM
 * before flashing it! YOU are choosing to make these modifications, and if
 * you point the finger at me for messing up your device, I will laugh at you.
 */

    CyanogenMod is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. Linked below is a package that has come from another Android project that restore the Google parts. CyanogenMod does still include various hardware-specific code, which is also slowly being open-sourced anyway.

    All the source code for CyanogenMod is available in the CyanogenMod Github repo. And if you would like to contribute to CyanogenMod, please visit out Gerrit Code Review. You can also view the Changelog for a full list of changes & features.

    Instructions:

    First time flashing CyanogenMod 7 to the Samsung Vibrant, or coming from another ROM?
    1. Root the device and install ClockworkMod Recovery. Instructions are available here.
    2. Perform a NANDroid backup of your current ROM.
    3. Format the system, data & cache partitions of your device.
    4. Perform a factory reset.
    5. Flash CyanogenMod.
    6. Optional: Install the Google Apps addon package.
    Upgrading from earlier version of CyanogenMod 7?
    1. Perform a NANDroid backup of your current ROM.
    2. Flash CyanogenMod (your Google Apps will be backed up & restored automatically).
    Issues?

    Please be aware that there are still issues with 911 calling for the Vibrant and possibly other Galaxy S phones in T-Mobile. The issue is specific to T-Mobile and the Samsung Galaxy S Radio Interface Layer.

    Experience issues? Please provide the following info:
    • If the device was hard reboot, please provide the file "/proc/last_kmsg".
    • If the device was soft reboot or is "bootlooping", please run a logcat and provide the full output.
    • Please use Pastebin when possible.
    Download Links:




    CyanogenMod:
    Latest version: update-cm-7.1.0.1-Vibrant
    Download: link
    Mirror: link
    MD5sum: 61102edc51f82e53271281b4a2853931​

    Google Apps addon:
    Version: gapps-gb-20110828
    Mirror: link
    Mirror: link

    Version: Google Talk with video addon
    Mirror: link
    Mirror: link​

    The CyanogenMod team would like to thank everyone involved in helping with testing, coding, debugging & documenting! Enjoy!
    View
    5
    renardk764
    renardk764
    I work in the 911 call center in Austin Texas. I own a vibrant and have been usning CM7 for a while.

    I've attached a logcat taken while attempting a 911 call. Result was a busy signal.

    BTW, I'll personnally test any solutions that are developed. I'm in a position where testing 911 phone calls won't cause a stir.

    It's important and many of you giving out alternative numbers really don't understand the complexity of modern 911 systems.

    Let me know ASAP if this logcat is informative or if I need to do something different.

    KenR
    View
    4
    G
    Genesis3
    Yikes - those files are very messy (e.g. no line separators in them!) but I think I found something that matches what I expected.

    I had to "tr" the file to be able to read it and there's no CRs in there either (from what platform did you pull these logcats?!) but there's a number of interesting things in here.

    Among them:

    Code: 
    0)E/RIL
  149): requestDialEmergencyCall
)E/RIL
  149): requestDialEmergencyCall
): address[911/], clir[0]E/RIL    
  149): TxCall_ExecOriginate
)E/RIL                                         
  149): TxCall_ExecOriginate
) number[911], number_len=3E/RIL                                 
  149): get_msg_sequence
)E/RIL                                                           
  149): ipc_debug_send_ipc: timestamp 1320507653306009E/RIL      
  149): IPC_send_singleIPC: fd 17 sendto 99 bytesE/RIL           
  149): TX: Time: 1952693434 / 2597205E/RIL
  149): TX:
M)IPC_CALL_CMD 
S)IPC_CALL_OUTGOING 
T)IPC_CMD_EXEC  len:63 mseq:f1 aseq:0E/RIL
  149): TX: ---- DATA BEGIN ----E/RIL
  149): TX: 00 07 00 03 21 39 31 31 00 00 00 00 00 00 00 00 E/RIL
  149): TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E/RIL
  149): TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E/RIL
  149): TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E/RIL
  149): TX: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 E/RIL
  149): TX: 00 00 00 00 00 00 00 00 00 00 00 00 E/RIL
  149): TX: ---- DATA  END ----E/RIL
  149): IPC_send_singleIPC: 99 bytes sent.E/RIL
  149): WaitForExpectedCmd
): cur_time: 2597205, cur_req->timeout: 2657205, ph->near_timeout: 2602202E/RIL

  149): ipc_debug_send_ipc: timestamp 1320507653326114E/RIL
  149): [EVT]:Req
2), RX
1)E/RIL    
  149): RX: Time: 1952693454 / 2597225E/RIL
  149): RX:
M)IPC_GEN_CMD 
  149): RX: ---- DATA BEGIN ----E/RIL
  149): RX: 09 02 03 00 80 E/RIL    
  149): RX: ---- DATA  END ----E/RIL
[b]  149): requestSetMute
)E/RIL    [/b]
  149): GR err: 0x8000E/RIL    
  149): COMPLETE - STATE[1] < E/RIL 
  149): RIL_onRequestComplete: tok
0x1b4b0)E/RIL    
  149): [RM REQ]: req
0x1b4c8), tok
0x1b4b0)E/RIL    
  149): [EVT]:Req
1), RX
0)E/RIL    
  149): [EVT]:Req
1), RX
0)D/RILJ   
  421): Serial: 1004D/RILJ   
  421): Error: 0D/RILJ   
 [b] 421): [1004]< SET_MUTE E/RIL[/b]

    There's the audio-channel mute.

    The problem appears to start here:

    Code: 
    S)IPC_CALL_STATUS
T)IPC_CMD_NOTI  len:d mseq:ff aseq:f1E/RIL
  149): RX: ---- DATA BEGIN ----E/RIL
  149): RX: 00 07 01 01 00 00 E/RIL
  149): RX: ---- DATA  END ----E/RIL
  149): ipc_recv_call
)E/RIL
  149): RxCall_CallStatusE/RIL
  149): prv_get_release_cause
0x0,0x0)E/RIL
  149): RIL_onMultiClientUnsolicitedResponse:E/RIL
  149): unsupported multiclient unsolicited response code 1001W/RILJ
  421): [1005]< <unknown request> exception, possible invalid RIL responseW/RILJ

  421): java.lang.RuntimeException: Unrecognized solicited response: 10016W/RILJ

  421):         at com.android.internal.telephony.SamsungRIL.processSolicited
SamsungRIL.java:240)W/RILJ
  421):         at com.android.internal.telephony.RIL.processResponse
RIL.java:2112)W/RILJ
  421):         at com.android.internal.telephony.RIL.access$300
RIL.java:208)W/RILJ
  421):         at com.android.internal.telephony.RIL$RILReceiver.run
RIL.java:583)W/RILJ
  421):         at java.lang.Thread.run
Thread.java:1019)D/RILJ
  421): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGEDE/RIL
  149): [EVT]:Req
0), RX
1)E/RIL
  149): RIL_onMultiClientUnsolicitedResponse:E/RIL
  149): unsupported multiclient unsolicited response code 1009D/RILJ
  421): [1006]> GET_CURRENT_CALLSE/RIL
  149): onRequest: GET_CURRENT_CALLSE/RIL
  149): CreateRequest
): req
0x1b718), id
9), tok
0x1b700) - FUNC
0x8001861d)E/RIL

    That exception is a problem; I've got nothing in the 10000s in the RILConstants.java file which strongly implies that this is one of those fancy-schmancy Samsung proprietary deals. If I had to guess that upcall is used in the stock code to provide an upbound notification that an emergency call is in process (perhaps to lock the phone to the call screen and prohibit exit until the calls ends, for example.) The Samsung RIL override file has unsolicited upcalls in the 11000s and a solicited 10016 that is related to emergency dialing.... hmmmm......

    This logcat output is radically different than what I get - what code version are you running? I'm on the release version (not the nightlies); it looks like the CM7 folks cranked the debugging data wide open in an attempt to find this, as I've got IPC-packet level trace data in the radio log you posted that isn't in my logs.

    Incidentally, contrast your log with a "working" ordinary call off the stable build. The 11003 exception is still here but it's the only one, and it is handled cleanly without tossing anything upstream.

    Code: 
    D/GSM     (  285): Poll ServiceState done:  oldSS=[0 home T-Mobile  T-Mobile  310260  UMTS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] newSS=[0 home T-Mobile  T-Mobile  310260  UMTS CSS not supported -1 -1RoamInd: -1DefRoamInd: -1EmergOnly: false] oldGprs=0 newGprs=0 oldType=UMTS newType=UMTS
D/GSM     (  285): isTwoDigitShortCode
D/GSM     (  285): dialing w/ mmi 'null'...
D/GSM     (  285): [GSMConn] acquireWakeLock
D/RILJ    (  285): [6919]> SET_MUTE false
D/RILJ    (  285): [6920]> DIAL
D/RILJ    (  285): Serial: 6919
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6919]< SET_MUTE
E/RILJ    (  285): Exception processing unsol response: 11003Exception:java.lang.RuntimeException: Unrecognized unsol response: 11003
D/RILJ    (  285): Serial: 6920
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6920]< DIAL
D/RILJ    (  285): [UNSL]< UNSOL_RESPONSE_CALL_STATE_CHANGED
D/RILJ    (  285): [UNSL]< <unknown reponse>
D/PHONE   (  285): VM: PhoneSubInfo.getVoiceMailNUmber:
D/RILJ    (  285): [6921]> GET_CURRENT_CALLS
D/RILJ    (  285): [6922]> GET_CURRENT_CALLS
D/RILJ    (  285): Serial: 6921
D/RILJ    (  285): Error: 0
D/RILJ    (  285): Parcel size = 96
D/RILJ    (  285): Parcel pos = 12
D/RILJ    (  285): Parcel dataAvail = 84
D/RILJ    (  285): num = 1
D/RILJ    (  285): state = DIALING
D/RILJ    (  285): index = 1
D/RILJ    (  285): state = 129
D/RILJ    (  285): isMpty = false
D/RILJ    (  285): isMT = false
D/RILJ    (  285): als = 0
D/RILJ    (  285): isVoice = true
D/RILJ    (  285): Samsung magic = 0
D/RILJ    (  285): number = 850xxxxxxx
D/RILJ    (  285): np = 0
D/RILJ    (  285): name = null
D/RILJ    (  285): namePresentation = 0
D/RILJ    (  285): uusInfoPresent = 0
V/RILJ    (  285): Incoming UUS : NOT present!
D/RILJ    (  285): InCall VoicePrivacy is disabled
D/RILJ    (  285): [6921]< GET_CURRENT_CALLS  [id=1,DIALING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0]
D/RILJ    (  285): Serial: 6922
D/RILJ    (  285): Error: 0
    Note that we got the 11003, but we also set the MUTE; (I blanked the nxx numbers); the call processes and then we get....
    Code: 
    V/RILJ    (  285): Incoming UUS : NOT present!
D/RILJ    (  285): InCall VoicePrivacy is disabled
D/RILJ    (  285): [6922]< GET_CURRENT_CALLS  [id=1,DIALING,toa=129,norm,mo,0,voc,noevp,,cli=1,,0]
D/RILJ    (  285): [6923]> OPERATOR
D/RILJ    (  285): [6924]> GPRS_REGISTRATION_STATE
D/RILJ    (  285): [6925]> REGISTRATION_STATE
D/RILJ    (  285): Serial: 6923
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6923]< OPERATOR {T-Mobile , T-Mobile , 310260}
D/RILJ    (  285): Serial: 6924
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6924]< GPRS_REGISTRATION_STATE {1, 865d, 045d21d5, 3}
D/RILJ    (  285): [6926]> QUERY_NETWORK_SELECTION_MODE
D/RILJ    (  285): Serial: 6925
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6925]< REGISTRATION_STATE {1, 865d, 045d21d5}
D/RILJ    (  285): Serial: 6926
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6926]< QUERY_NETWORK_SELECTION_MODE {0}
D/RILJ    (  285): [6927]> SET_MUTE false
D/RILJ    (  285): Serial: 6927
D/RILJ    (  285): Error: 0
D/RILJ    (  285): [6927]< SET_MUTE
D/RILJ    (  285): [6928]> SET_MUTE false
    There it is - mute is TURNED OFF.

    First blush it looks to me like the blowup in the call state is killing it.

    The code attempts to un-mute and manage that state exactly as it does for a normal call. There's a ****ton of debugging trace data in your logs that aren't present in mine looking at an ordinary call setup. I don't see anything obvious there; the "zero" error returns are present.

    My money is on the exception being thrown right at the top being responsible for the problem, but this is an educated guess at present.

    Now let's see what we got in that Samsung RIL file for 10016...

    Code: 
        static final int RIL_REQUEST_DIAL_EMERGENCY = 10016;

.....

        if (PhoneNumberUtils.isEmergencyNumber(address)) {
            Log.v(LOG_TAG, "Emergency dial: " + address);
            rr = RILRequest.obtain(RIL_REQUEST_DIAL_EMERGENCY, result);
            rr.mp.writeString(address + "/");
        }
    Aha. So we send up a 911 request with that code but what do we do if we get a response back with the same index?

    Upstream in the code a bit we have this:
    Code: 
                case RIL_REQUEST_REPORT_SMS_MEMORY_STATUS: ret = responseVoid(p); break;
            case RIL_REQUEST_REPORT_STK_SERVICE_IS_RUNNING: ret = responseVoid(p); break;
            default:
                throw new RuntimeException("Unrecognized solicited response: " + rr.mRequest);
            //break;

    Uh huh. See that nice last default case? Bad news; that's the blowup in your log. I betcha we stick this in there right above it and the problem goes away:
    Code: 
             case RIL_REQUEST_DIAL_EMERGENCY: ret = responseVoid(p); break;

    I haven't grabbed the entire build set yet for the Vibrant so I'm working off my other local copy (which I build the Triumph from) so this is somewhat of a guess right now; my Linux VM is too small to grab another full tree and one of this weekend's jobs is to resize it onto another disk so I can work on the Vibrant code.

    I'll try to get this done over the weekend and build up a KANG for you to try; if the official CM7 folks see this it's a literal one-liner to see if it solves the problem, but since they don't have a Vibrant to test on it's a ***** for them to check it.

    atinm said:
    Umm, what is actually happening is that the audio routing isn't happening. We haven't figured out whether it is because the RIL layer needs to be told to do something we haven't found (nothing to do with the kernel). We call into the RIL in the same way we do for Normal calls, with a light difference (which is how stock does it too), the call goes thru, but no audio is routed in either direction. We're not completely sure if there is some other thing that needs to happen on the callback that we're not doing because Samsung is known to go around APIs when doing special things in the Galaxy S series.
    Click to expand...
    Click to collapse

    Unless I'm reading the radio logcat wrong the routing and unmute is just fine - the problem is that the phone code got blown up by the unhandled exception during call setup and thus there's nothing to route from and to any more!

    Thou shalt not send a request that can generate a response and not handle the response!
    View
    3
    eugene373
    eugene373
    marlopainter said:
    I literally just did the same thing and got the same result, lol.
    Click to expand...
    Click to collapse

    when it does this, Reboot into recovery via 3-button combo without USB plugged in..

    Once the CM Recovery Loads
    Wipe Data / Factory reset
    Wipe Cache

    &

    Re-install CM7
    All Done..
    View
    3
    eugene373
    eugene373
    Kaik541 said:
    as far as other kernels go, I really don't mind the random discussions about glitch or neo or whatever, but please, for the love of God, do not discuss Eugene's kernels here on this thread.

    he doesn't share source code, he violates his legal obligation to the GPL, and he refuses to give back to the community he is taking all the basis for his work from. he is a glory hog who just wants everyone to praise him and is not looking out for the best interest of the users, but only the best interest of his paypal account
    Click to expand...
    Click to collapse

    See I can Troll Too!
    troll_face_in_640_14.jpg


    Rant over!
    Thanks,
    ~Eugene
    View

New posts